关于分布式内存级缓存的分块逻辑

[liudaac]

需求背景
以1.0.0版本为参考，对分布式内存的缓存，基础框架采用了Caffeine，使用方式上集成spring-cache标准实现独立的CacheManager。通知机制支持ZK以及Nacos，通知级别支持到CacheName级，更新的方式主要是各节点通过对CacheName版本的监听，实现CacheName级别的Evict，在关联缓存被查询时进行重新生成。
关于数据的变更，此处除了版本机制外还有一个考量，是Jraft的集成，但考虑到jraft更适合独立功能集群的部署，如果普遍性的集成到业务中会造成不必要的开销，并增加了业务的复杂度，所以并未使用该方案。

优化点

• 内存级缓存的落地场景一般的是高并发下减少redis的io调用，如果CacheName下存在大量的Keys，Evict操作会导致内存层面缓存风暴的产生，该层面缓存风暴的影响依赖后面承接的存储层方案相关。比如Redis是可接受的。
• 通过nacos、zk这种一致性中间件实现的版本广播机制，对于节点与之断联但服务可用场景下，存在数据不一致的问题。那异常节点对该问题的感知机制则需要明确

解决方案

• 其实面对的是大量Keys与单个CacheName绑定导致的同时失效的问题

1. reload机制。当然此处不能考虑将所有的key进行reload，这样对服务的压力不可控。可以考虑记录最近活跃的hotkey进行针对性的reload
2. CacheName-keys的映射关系调整为CacheName-region-keys的关系，从而按照region将keys进行再分组，以降低某个key更新时影响的范围，region个数建议是可配置的并规定上限，依key的数量进行划分。但这样也会衍生出一个新的问题，就是region数的变更，当业务量增长或者预估过多，原有region个数需要调整时，需要考虑各节点的更新以及key重分组的问题。
3. 既然涉及到region，就需要实现数据分片算法，主要目的是将CacheKeys尽量均匀分布到各region中
4. 除了分片算法的考量，还需要考虑region个数的变更策略问题，支持动态变更还是配置级变更后进行重启。动态变更其实和配置级变更是一个思路，因为配置级变更，我们往往希望第一个重启的节点能够主动发现region个数的更改，并通知到其他兄弟节点，这样能够降低集群中间态的影响，如果设想一个6节点集群，采用滚动发布策略，如果第一个节点不去做这个事情，那么，对于新节点触发的数据版本通知就会发生错乱，因为旧节点可能还未更新。也就是可以理解为配置级变更无法省掉分片数同步这一个环节，但相对于动态变更，配置级变更还有一个缺陷，就是重启后所有节点的内存信息仍然会重新加载初始化。既然这样，还不如选择动态变更策略。
5. 当然，动态变更策略也不是万能的，仍然需要确定一个问题，不论是region个数的增加还是减少，我们希望是对其中一部分region的操作和重构，而保持一部分region不变，这样可以避免旧region中的数据冗余问题，当然这主要是依赖分片算法的设计。
6. 为了提供可观测性，需要提供各region的使用状态查询。另外还要注意，是什么样的场景下，参考什么样的metric，我们需要进行region个数的变更。

• 类似微服务组件中，客户端和注册中心的双向联系。可以考虑在节点上增加定时心跳机制，定时从一致性中心进行版本信息的拉取。当网络出现问题时，能够在容忍的时间阈值内感知到，并能将内存缓存层剔除，直接读取后端数据。不过时间间隔不宜过短，会对一致性协调中心造成额外压力。

多实例的性能损耗

• 如果单纯的进行多CaffeineCache实例的构造，需要注意的是Caffine本身有基于时间轮的缓存淘汰策略，实例数随着分片数的增加而增加会不会带来多余的线程损耗，这一点需要进行确认。如果确实如此，则需要在Caffeine内增加分片的路由逻辑，防止过多的线程开销。

内存占用：每个Caffeine实例都需要一定的内存来存储缓存数据和相关的数据结构。因此，如果创建了太多的实例，可能会导致内存占用过高，从而影响系统性能和稳定性。具体开销可以参考【https://github.com/ben-manes/caffeine/wiki/Memory-overhead-zh-CN】
线程池资源：每个Caffeine实例都需要一个独立的线程池来执行缓存项的加载和计算操作。如果创建了太多的实例，可能会导致线程池资源过度分散，从而影响线程的执行效率和响应速度。
初始化时间：每个Caffeine实例都需要一定的初始化时间来创建数据结构、线程池等资源。如果创建了太多的实例，可能会导致系统启动时间过长，从而影响用户体验和系统稳定性。

综上可以看出，我们最好的方案还是在Caffeine内的ConcurrentHashMap上层增加一层桶的逻辑，用来做Key的离散分布。

如果要实现我们的想法，还是需要从Caffeine Cache的具体实现入手。众所周知，Cache实例的创建是由Caffeine.newBuilder().build()，那么就需要从此处开始，看看Caffine在构造Cache实例的过程究竟做了什么，构造出来的实例长成什么样子？

Caffeine的构造

• Caffeine为我们准备了两个大类的Cache实现，即有界Cache和无界Cache，分别对应到BoundedLocalCache.BoundedLocalManualCache和UnboundedLocalCache.UnboundedLocalManualCache，这两类对象的构造方法则以Caffeine作为了入参，用来传入配置参数。对于线上使用场景而言，我们会更专注于有界Cache；
• BoundedLocalManualCache中包装了BoundedLocalCache实例，作为Cache的核心实现。而BoundedLocalCache的构造是通过静态方法构造得到

LocalCacheFactory.newBoundedLocalCache(builder, loader, /* async */ false);

• 而到了newBoundedLocalCache的实现，会发现一个神奇的东西，它第一步通过Caffine的配置项将对应的大写字母组合生成了ClassName，后面则通过loadFactory方法的调用，按ClassName获取到Class然后进行构造。从而生成了BoundedLocalCache<K,V>实例。需要注意的是，这些大写字母组成的Class在源码中是没有的，而是在编译阶段通过JavaPoet生成出来，并且全部继承了BoundedLocalCache，可以理解为以不同class的方式依据配置对BoundedLocalCache这个基础实现进行了装饰。（这个代码生成方式贯穿于整个Caffine的实现，除了此处Cache的实现类之外，Node的实现也是如此。）

private static final MethodType FACTORY = MethodType.methodType(
      void.class, Caffeine.class, AsyncCacheLoader.class, boolean.class);
static <K, V> BoundedLocalCache<K, V> loadFactory(Caffeine<K, V> builder,
      @Nullable AsyncCacheLoader<? super K, V> cacheLoader, boolean async, String className) {
    try {
      Class<?> clazz = Class.forName(className);
      MethodHandle handle = LOOKUP.findConstructor(clazz, FACTORY);
      return (BoundedLocalCache<K, V>) handle.invoke(builder, cacheLoader, async);
    } catch (RuntimeException | Error e) {
      throw e;
    } catch (Throwable t) {
      throw new IllegalStateException(className, t);
    }
  }

• 其实到这我们已经可以初步摸到需要重点关注的位置，就是所有Cache的基础实现类型BoundedLocalCache，接下来就看看这个类的实现对于我们分桶的设想有没有帮助

BoundedLocalCache

这个类的核心，在于final ConcurrentHashMap<Object, Node<K, V>> data。BoundedLocalCache在data的上层进行了包装，在put时首先使用Key，Value构造出Node对象

node = nodeFactory.newNode(key, keyReferenceQueue(),
              value, valueReferenceQueue(), newWeight, now);

然后再将其put到data中

data.putIfAbsent(node.getKeyReference(), node);

那这个思路其实已经很明朗，如果改造为桶的模式，那么唯一的方式就是往ConcurrentHashMap上进行封装，那么改造Caffeine源码涉及定制发布等问题，所以其实可以直接在我们的代码中将Key这一级做Caffeine外层的处理，这一层将Key进行桶的划分和记录，并通过Caffine的Key事件进行动态维护，当然会在存储上带来一定的开销，不过对于内存缓存的使用场景中，第一我们对Key的记录还是以引用的方式，第二Key相比于Value来说还是较小的，所以可以认为与内存级快速更新带来的好处相比，这些开销是可接受的，额外的存储开销我们会在后续性能测试中给出详细的数据。接下来，就说说以aradin-spring-caffine为基础如何进行该方案的实现。
#36