1. 设计概述

1.1. 代码结构

1. 为了提升功能代码的内聚性，通过设计ILastCacheContainer接口，将LastCache操作与MNode解耦，由LasCacheContainer实现ILastCacheContainer接口，封装lastCache数据同时提供简单的lastCacheValue操作。
2. 新建LastCacheManager，将MManager中与lastCache相关的操作代码尽可能迁移至 LastCacheManager，MManager中仅保留必要的mtree调用以及mnode获取操作。

1.2. 适配物理量模板

由于Template由EntityMNode进行使用，因此在EntityMNode中增加Map<String, ILastCacheContainer>字段，用于存储template所表示的时间序列的lastCache。

因此EntityMNode中存储模板对应序列的lastCache，MeasurementMNode中存储普通序列的lastCache。

1.3. 适配多元序列

设计VectorLastCacheValue，存储多元时间序列的lastCache；由于目前last查找是查找最新的不为空值的时间点，故不同分量的LastCache时间可能不同，需要存储多个timestamp和 TsPrimitiveValue。

ILastCacheContainer提供基于分量Index的lastCache操作接口，该index与vector schema中的分量index相一致。

2. 类设计

3. 调用场景及执行过程

3.1. last cache查询

last cache查询主要由LastQueryExecutor中的LastCacheAccessor进行调用。

1. LastCacheAccessor通过调用MManager.getNodeByPath(PartialPath path)获取序列对应的MeasurementMNode
   1. 如果是普通一元序列，则正常返回MeasurementMNode
   2. 如果是template表示的序列，则将对应的序列schema与封装为临时的MeasurementMNode返回
   3. 如果是多元序列，则传入的路径应是目标分量的全路径，返回该多元序列对应的MeasurementMNode
   4. 如果是template表示的多元序列，则结合b和c两种处理方式，b中封装的schema将为VectorMeasurementSchema
2. LastCacheAccessor调用MManager.getLastCache(PartialPath seriesPath, IMeasurementMNode node)
   1. 若1中的操作成功，则可同时传入path与node，避免MManager对measurementMNode的二次查找，并且多元序列场景中path可表明具体的目标分量。
   2. 若1中节点获取失败，则尝试仅基于path查找lastCache结果，此时MManager会基于path进行MeasurementMNode查找
3. MManager调用LastCacheMManager的getLastCache接口
   1. 判断是否为template表示的序列，即判断传入的measurementMNode的parent EntityMNode是否有对应的子节点，若无则从EntityMNode中获取到LastCacheContainer并赋予该measurementMNode
   2. 如果是一元序列，获取measurementMNode中的lastCacheContainer后获取其持有的lastCacheValue
   3. 如果是多元序列，需基于path获取分量名，再从schema中获取分量的index然后再从lastCacheContainer获取lastCacheValue

2中情况的一个典型场景为分布式中，node的获取不会返回本地缓存的remote measurementMNode，但是lastCache查询可以先走remote  measurementMNode中进行查询。

3.2. last cache更新

3.2.1. Last Query执行过程中的last cache更新

last查询过程中，若cache miss，则会从文件中读取last value，并且将该值进行缓存，此时LastCacheAccesso将调用MManager的updateLastCache接口。

与getLastCache接口类似，updateLastCache接口也可以path和node双参数传入。

1. 如果LastCacheAccessor先前已成功获取node，则将path与node同时传入，MManager避免node的二次查找
2. LastCacheAccessor先前未获取到node，则传入path，此时node为null，MManager将基于path查找对应node
3. MManager调用LastCacheManager的updateLastCache接口，不同类型序列的处理逻辑与3.1中3的逻辑大致相同

3.2.2. insertPlan执行过程中的last cache更新

insertPlan执行过程中，插入的数据的最新点需缓存，由StorageGroupProcessor调用MManager的updateLastCache接口。

为了解决insert和last query的并发更新，updateLastCache中设置priority参数，insert的last cache更新优先级高于last query。

3.3. last cache 清除

3.3.1. delete执行过程中的last cache清除

StorageGroupProcessor在执行delete的过程中，会基于用户输入的originPath以device为单位进行删除操作，lastCache的删除过程中需根据删除数据的起始时间进行判断是否要清空缓存。

因此MManager提供deleteLastCacheByDevice(PartialPath deviceId, PartialPath originalPath, long startTime, long endTime)接口，MManager获取节点后，具体清除逻辑由LastCacheManager进行执行。

EntityMNode中template的LastCacheContainer与MeasurementMNode的LastCacheContainer均需检查是否需要清空。

3.3.2. upload tsfile执行过程中的last cache清除

upload tsfile后由于引入了新数据，需将对应序列的last cache清空，此过程也是以device为单位进行执行。

MManager提供deleteLastCacheByDevice(PartialPath deviceId)接口，MManager获取节点后，具体清除逻辑由LastCacheManager进行执行。

EntityMNode中template的LastCacheContainer与MeasurementMNode的LastCacheContainer均会被清空。

4. LastCache扩展方向

1. LastCache缓存多条数据，LastCacheContainer向BatchedLastCacheContainer扩展
2. 底层实现重写，如lastCache存储Memtable中最新的批量数据