分布式多级缓存SDK设计的思考

背景
整体架构
- 多层级组装
- 回调埋点
- 分区处理
- 一致性问题
- - 缓存与数据库之间的一致性问题
  - 不同层级缓存之间的一致性问题
  - 不同微服务实例上，非共享缓存之间的一致性问题
小结

之前实习期间编写过一个简单的多级缓存SDK，后面了解到一些其他的开源产品，如J2Cache，京东的JdHotKey，有赞的多级缓存SDK实现，所以本文想来总结一下我对多级缓存SDK设计的考量和开发心得。

参考的相关开源实现链接:

有赞透明多级缓存解决方案（TMC）
J2Cache
hotkey
实战干货 | 分布式多级缓存设计方案

背景

编写这个SDK起因于部门各个服务缓存使用上的不统一，有些没有使用缓存，有些单独使用了本地缓存或者Redis集中式缓存，还有些使用了阿里的Tair缓存，因此为了结束缓存使用混乱的局面，就有了这个多级缓存SDK Demo 。

我们期望这个多级缓存SDK能够满足以下目标:

支持自定义缓存层级和缓存层级之间的顺序，例如: 可以是Caffeine+Redis的组合，也可以是Caffeine + Tair + Redis的组合
需要与链路追踪工具Cat结合，定时上报缓存工作状态，如: 全局缓存命中率，各级缓存命中率等
需要支持灰度与开关机制，灰度用于控制走缓存比例，开关用于上下线该SDK，或者单独上下线某一级缓存
需要处理好缓存穿透，缓存击穿，缓存与数据库一致性，多级缓存间的一致性，以及分布式环境下，各个实例上非共享的L1级缓存的一致性问题。

以上四点是我目前所能想到的内容，也是我所开发的SDK支持的功能，如果大家有补充欢迎在评论区留言。

下面我将从整体架构讲起，一直聊到以上所说的细节实现。

整体架构

多级缓存SDK整体架构如何所示:

在这里插入图片描述

CacheFacade 作为缓存门面对象，向用户屏蔽了内部多个模块协同工作的复杂性，同时负责编排多级缓存 get 和 set 的模版流程，并在相关位置进行回调埋点，方便后续扩展。
CacheRepository 作为多级缓存实现，采用装饰器模式层级嵌套关系，缓存的 get 流程是先走低层级缓存，再走高层级缓存；set 和 del 流程是先走高层级缓存，再走低层级缓存。
CacheConfig 作为配置模块，收拢了整个缓存SDK所有的配置项，同时采用SPI机制可以实现配置中心的动态切换，默认只提供了ApolloConfigProvider，用于支持Apollo作为配置中心。
CachePostProcessor 顶层提供了相关默认接口实现，如果我们希望能够在缓存执行的某个流程处进行监听，可以重写相关接口实现，添加对应的拦截逻辑，然后将自身交于缓存后置处理模块管理即可。
CacheCluster 负责实现多个实例之间的非共享L1级缓存的一致性，当有请求试图在某个实例上执行set或者del操作时，都需要广播告知其他实例，用于清除自身的L1级缓存。

整个缓存SDK的架构还是非常简单的，下面我将针对各处细节进行说明。

多层级组装

多级缓存SDK默认情况下会提供Caffeine+Redis的两级缓存，但是如果业务有特殊需求，不满足于此，我们也可以自定义缓存层级 :
在这里插入图片描述
为了支持自定义缓存层级，这里采用装饰器模式的层层装饰来实现多级缓存的效果，伪代码如下图所示:

public abstract class AbstractCacheRepositoryWrapper implements CacheRepository {private final CacheRepository wrappedCacheWrapper;public AbstractCacheRepositoryWrapper(CacheRepository wrappedCacheWrapper) {this.wrappedCacheWrapper = wrappedCacheWrapper;}...
}

接入方只需要为接入的缓存提供一个CacheRepository实现，并且自行完成装饰层级的嵌套组装，最后将组装得到的对象实例交由CacheFacade管理即可；如果项目使用到了Spring ，这里可以将对象实例注入容器，CacheFacade 由容器中取得即可。

回调埋点

CacheFacade 作为缓存门面对象，向用户屏蔽了内部多个模块协同工作的复杂性，同时负责编排多级缓存 get 和 set 的模版流程，并在相关位置进行回调埋点，方便后续扩展。

因为 CacheFacade 拿到的其实是已经组装完毕的多级缓存对象，如下图所示:
在这里插入图片描述
所以这里 get 和 set 请求要分为两段来看，一段是存在于缓存门面对象中设定好的模版流程，另一段是存在于AbstractCacheRepositoryWrapper中设定好的多级缓存间的get，set，del 流程。

我们先来看看缓存门面对象中设置设定好的模版流程和相关回调埋点的工作时机:

get 流程

在这里插入图片描述

当缓存失效需要重建的时候，为了避免多个实例并发重建，可以考虑使用逻辑过期+分布式锁确保只有一个实例会去执行重建操作。

list 流程
set 流程

在这里插入图片描述

del 流程

在这里插入图片描述

上面可以理解为全局缓存的执行流程，下面我们来看看存在于AbstractCacheRepositoryWrapper中设定好的多级缓存间的get，set，del 流程:

get 流程

在这里插入图片描述

list 流程

在这里插入图片描述

set 流程

在这里插入图片描述

del 流程

在这里插入图片描述
上述流程图中各处埋点均以绿色标出，每当执行到埋点处时，都会去调用后置处理器链，后置处理器又分为全局后置处理器和局部后置处理器，前者工作在缓存门面设定的全局流程中，后者工作在多级缓存的局部流程中。

如果后续有扩展需求，只需要自定义一个后置处理器，加入后置处理器链中即可。

分区处理

我是从J2Cache中了解到的分区Region的思想，也在随后添加到了我自己开发的多级缓存SDK中，这里简单介绍一下为什么我们需要分区：

在实际的缓存场景中，不同的数据会有不同的 TTL 策略，例如有些缓存数据可以永不失效，而有些缓存我们希望是 30 分钟的有效期，有些是 60 分钟等不同的失效时间策略。在 Redis 我们可以针对不同的 key 设置不同的 TTL 时间。但是一般的 Java 内存缓存框架（如 Ehcache、Caffeine、Guava Cache 等），它没法为每一个 key 设置不同 TTL，因为这样管理起来会非常复杂，而且会检查缓存数据是否失效时性能极差。所以一般内存缓存框架会把一组相同 TTL 策略的缓存数据放在一起进行管理。
通过分区可以将属于不同业务的缓存隔离开来，防止相互污染，比如我们使用LRU缓存，所有业务共用一个LRU缓存，如果业务A总是大批次查询，那么可能会将其他业务热点key给淘汰出去，造成污染问题。

采用分区之后，CacheFacade 门面对象内部也就不是简单持有一个多级缓存实例对象了，而是持有一个多级缓存实例映射集合，如下图所示:

在这里插入图片描述
此时，我们的 get 和 set 等方法也都需要改造，在方法参数处添加一个 region，指明要操作哪个 region。