一款牛逼的多级缓存架构设计方案

• 活动时间、活动类型、活动商品之类的信息不可预期，导致 缓存热点访问 情况不可提前预知；

• 缓存热点访问 出现期间，应用层少数 热点访问 key 产生大量缓存访问请求：冲击分布式缓存系统，大量占据内网带宽，最终影响应用层系统稳定性；

为了应对以上问题，需要一个能够 自动发现热点并将热点缓存访问请求前置在应用层本地缓存的解决方案，这就是 TMC 产生的原因。

多级缓存解决方案的痛点

---

基于上述描述，我们总结了下列 多级缓存解决方案 需要解决的需求痛点：

• 热点探测：如何快速且准确的发现 热点访问 key ？

• 数据一致性：前置在应用层的本地缓存，如何保障与分布式缓存系统的数据一致性？

• 效果验证：如何让应用层查看本地缓存命中率、热点 key 等数据，验证多级缓存效果？

• 透明接入：整体解决方案如何减少对应用系统的入侵，做到快速平滑接入？

TMC 聚焦上述痛点，设计并实现了整体解决方案。以支持“热点探测”和“本地缓存”，减少热点访问时对下游分布式缓存服务的冲击，避免影响应用服务的性能及稳定性。

TMC 整体架构

---

TMC 整体架构如上图，共分为三层：

• 存储层：提供基础的 kv 数据存储能力，针对不同的业务场景选用不同的存储服务（codis/zankv/aerospike）；

• 代理层：为应用层提供统一的缓存使用入口及通信协议，承担分布式数据水平切分后的路由功能转发工作；

• 应用层：提供统一客户端给应用服务使用，内置“热点探测”、“本地缓存”等功能，对业务透明；

本篇聚焦在应用层客户端的“热点探测”、“本地缓存”功能。

TMC 本地缓存

---

如何透明

TMC 是如何减少对业务应用系统的入侵，做到透明接入的？对于公司 Java 应用服务，在缓存客户端使用方式上分为两类：

• 基于 spring.data.redis包，使用 RedisTemplate编写业务代码；

• 基于 youzan.framework.redis包，使用 RedisClient编写业务代码；

不论使用以上那种方式，最终通过 JedisPool创建的 Jedis对象与缓存服务端代理层做请求交互。

TMC 对原生 jedis 包的 JedisPool和 Jedis类做了改造，在 JedisPool 初始化过程中集成 TMC“热点发现”+“本地缓存”功能 Hermes-SDK包的初始化逻辑，使 Jedis客户端与缓存服务端代理层交互时先与 Hermes-SDK交互，从而完成 “热点探测”+“本地缓存”功能的透明接入。

对于 Java 应用服务，只需使用特定版本的 jedis-jar 包，无需修改代码，即可接入 TMC 使用“热点发现”+“本地缓存”功能，做到了对应用系统的最小入侵。推荐：