关于分布式内存缓存的失效刷新逻辑

[liudaac]

缓存失效

常规情况下内存缓存失效的情况有5种：

• 1.自动型，单Key缓存超时或LRU自动失效；
• 2.手动型，单Key数据发生更新，缓存失效；
• 3.主动型，类似版本变更的事件，标识前置缓存数据整体失效，需要重载；
• 4.被动型，当缓存所在的服务节点发生重启或者宕机等导致内存整体失效；
• 5.GC触发，因为在内存缓存的使用上，从Java虚拟机的实现角度上，为了保证引入内存缓存后不影响堆上服务的内存分配，有时会选择在Value引用的级别上接入软引用，这样的结果就是缓存可能受到GC的影响，当堆上内存空间不足时，这些缓存会有丢失的风险。

从内存框架的角度而言，情况1和情况2并不需要关注，因为在缓存的使用中，单Key级别超时自动失效和数据变更后的逻辑我们认为是可控的，即可以通过Key级别人工或注入Reload方法的重刷逻辑来做更新或丢弃。

情况5发生时，以内存的重要程度上而言，在内存不足时为了保证服务的正常，做一些缓存上的舍弃是必要的，此时基本上也无需再将缓存重新申请出来进行占用，而是需要通过整体服务的监测，比如缓存命中率、接口延时等，对缓存或者运行时内存进行优化来解决。

也就是说需要关注的，是情况3和情况4，这两种情况既有不同也有相同。不同在于，在服务的运行状态上，4会出现重启后状态的丢失，3则不会，因为虽然版本触发了Cache级别的缓存失效，但服务维持在运行时。相同点就是对于调用方而言，服务侧的缓存都出现了成块的缺失，这必然会导致之前为了优化调研性能在内存缓存上的工作短时间内处于失效状态。

缓存重载

为了避免块缓存失效而导致流量击穿到Redis or DB，需要增加一个机制将数据重新loading到Cache中。Loading的选择就分为两种，全量和热点。当然对于轻量级应用的话，全量的刷新机制是可以接受的。但是框架需要应对重度缓存需求，这就需要考虑从Caffeine中快速定位出指定量的HotKeys更新至候选刷新集合。HotKeys的筛选，也划分出了两种策略：

• 自动策略：基于Caffeine本身的驱逐策略获取最近n个key-value对。参考Caffeine驱逐策略
• 手动策略：根据业务属性增加白名单策略，这块得涉及扩展Repository的方式留给业务自实现

自动策略

• 若为版本变更触发：
  此时服务处于存活状态，替换的逻辑是新建Cache实例，将最新引用指向到新Cache后，失效旧实例。

刷新的逻辑可以在变更引用指向前，基于Caffeine的API按照预设数量（注：这个数量要以数据量大小、重载时长、命中率影响进行预估）将HotKeys拉取出来，传递到新实例中使用线程池进行异步重载。

而引用变更的时机，是等异步重载完还是直接变更，需要视数据及时性对业务的影响而定。默认情况下，我们认为版本变更，旧缓存需及时失效，也就是触发异步重载后无需等待完成，即时将引用指向到新缓存实例，但这会造成在缓存预热阶段产生一定量的缓存击穿，需要依赖后置的Redis进行托底。或者，还有一种方式，我们对HotKeys再进行热度的切割，部分即时部分异步，这样能够进一步在缓存失效和更新及时上做一个平衡。

此外，面对线上应用场景，为了给参数的设定提供参考，需要对缓存重载进行预估和记录，提供特定的Metrics方便参数调优。