点击上方蓝色“
石杉的架构笔记”，选择“设为星标”
回复“PDF”获取独家整理的学习资料！
来源：
https://tech.youzan.com
-
为什么要做 TMC
-
TMC 整体架构
-
TMC 本地缓存
-
热点发现
-
整体流程
-
数据收集
-
热度滑窗
-
热度汇聚
-
热点探测
-
特性总结
-
实战效果
-
快手商家某次商品营销活动
-
双十一期间部分应用 TMC 效果展示**
-
功能展望
TMC，即“透明多级缓存（Transparent Multilevel Cache）”，是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。
TMC 在通用“分布式缓存解决方案（如 CodisProxy + Redis，如有赞自研分布式缓存系统 zanKV）”基础上，增加了以下功能：
-
应用层热点探测
-
应用层本地缓存
-
应用层缓存命中统计
以帮助应用层解决缓存使用过程中出现的热点访问问题。
为什么要做 TMC
使用有赞服务的电商商家数量和类型很多，商家会不定期做一些“商品秒杀”、“商品推广”活动，导致“营销活动”、“商品详情”、“交易下单”等链路应用出现
缓存热点访问
的情况：
为了应对以上问题，需要一个能够 自动发现热点 并 将热点缓存访问请求前置在应用层本地缓存的解决方案，这就是 TMC 产生的原因。
多级缓存解决方案的痛点
基于上述描述，我们总结了下列
多级缓存解决方案
需要解决的需求痛点：
-
热点探测：如何快速且准确的发现
热点访问 key
？
-
数据一致性：前置在应用层的本地缓存，如何保障与分布式缓存系统的数据一致性？
-
效果验证：如何让应用层查看本地缓存命中率、热点 key 等数据，验证多级缓存效果？
-
透明接入：整体解决方案如何减少对应用系统的入侵，做到快速平滑接入？
TMC 聚焦上述痛点，设计并实现了整体解决方案。以支持“热点探测”和“本地缓存”，减少热点访问时对下游分布式缓存服务的冲击，避免影响应用服务的性能及稳定性。
TMC 整体架构
TMC 整体架构如上图，共分为三层：
-
存储层：提供基础的 kv 数据存储能力，针对不同的业务场景选用不同的存储服务（codis/zankv/aerospike）；
-
代理层：为应用层提供统一的缓存使用入口及通信协议，承担分布式数据水平切分后的路由功能转发工作；
-
应用层：提供统一客户端给应用服务使用，内置“热点探测”、“本地缓存”等功能，对业务透明；
本篇聚焦在应用层客户端的“热点探测”、“本地缓存”功能。
TMC 本地缓存
如何透明
TMC 是如何减少对业务应用系统的入侵，做到透明接入的？对于公司 Java 应用服务，在缓存客户端使用方式上分为两类：
不论使用以上那种方式，最终通过
JedisPool
创建的
Jedis
对象与缓存服务端代理层做请求交互。
TMC 对原生 jedis 包的
JedisPool
和
Jedis
类做了改造，在 JedisPool 初始化过程中集成 TMC“热点发现”+“本地缓存”功能
Hermes-SDK
包的初始化逻辑
使
Jedis
客户端与缓存服务端代理层交互时先与
Hermes-SDK
交互，从而完成 “热点探测”+“本地缓存”功能的透明接入。
对于 Java 应用服务，只需使用特定版本的 jedis-jar 包，无需修改代码，即可接入 TMC 使用“热点发现”+“本地缓存”功能，做到了对应用系统的最小入侵。
整体结构
模块划分
TMC 本地缓存整体结构分为如下模块：
-
Jedis-Client
：Java 应用与缓存服务端交互的直接入口，接口定义与原生 Jedis-Client 无异；
-
Hermes-SDK
：自研“热点发现+本地缓存”功能的 SDK 封装，Jedis-Client 通过与它交互来集成相应能力；
-
Hermes 服务端集群
：接收 Hermes-SDK 上报的缓存访问数据，进行热点探测，将热点 key 推送给 Hermes-SDK 做本地缓存；
-
缓存集群
：由代理层和存储层组成，为应用客户端提供统一的分布式缓存服务入口；
-
基础组件
：etcd 集群、Apollo 配置中心，为 TMC 提供“集群推送”和“统一配置”能力；
基本流程
1）key 值获取
-
Java 应用调用
Jedis-Client
接口获取 key 的缓存值时，
Jedis-Client
会询问
Hermes-SDK
该 key 当前是否是
热点key
；
-
对于
热点key
，直接从
Hermes-SDK
的 热点模块 获取热点 key 在本地缓存的 value 值，不去访问
缓存集群
，从而将访问请求前置在应用层；
-
对于非
热点key
，
Hermes-SDK
会通过
Callable
回调
Jedis-Client
的原生接口，从
缓存集群
拿到 value 值；
-
对于
Jedis-Client
的每次 key 值访问请求，
Hermes-SDK
都会通过其 通信模块 将
key 访问事件
异步上报给
Hermes 服务端集群
，以便其根据上报数据进行“热点探测”；
2）key 值过期
-
Java 应用调用
Jedis-Client
的
set()
del()
expire()
接口时会导致对应 key 值失效，
Jedis-Client
会同步调用
Hermes-SDK
的
invalid()
方法告知其“key 值失效”事件；
-
对于
热点 key
，
Hermes-SDK
的 热点模块 会先将 key 在本地缓存的 value 值失效，以达到本地数据
强一致
。同时 通信模块 会异步将“key 值失效”事件通过
etcd 集群
推送给 Java 应用集群中其他
Hermes-SDK
节点；
-
其他
Hermes-SDK
节点的 通信模块 收到 “key 值失效”事件后，会调用 热点模块 将 key 在本地缓存的 value 值失效，以达到集群数据
最终一致
；
3）热点发现
4）配置读取
稳定性
TMC 本地缓存稳定性表现在以下方面：
-
数据上报异步化：
Hermes-SDK
使用
rsyslog技术
对“key 访问事件”进行异步化上报，不会阻塞业务；
-
通信模块线程隔离：
Hermes-SDK
的 通信模块 使用独立线程池+有界队列，保证事件上报&监听的 I/O 操作与业务执行线程隔离，即使出现非预期性异常也不会影响基本业务功能；
-
缓存管控：
Hermes-SDK
的 热点模块 对本地缓存大小上限进行了管控，使其占用内存不超过 64MB（LRU），杜绝 JVM 堆内存溢出的可能；
一致性
TMC 本地缓存一致性表现在以下方面：
-
Hermes-SDK
的 热点模块 仅缓存
热点 key
数据，绝大多数非热点 key数据由
缓存集群
存储；
-
热点 key
变更导致 value 失效时，
Hermes-SDK
同步失效本地缓存，保证
本地强一致
；
-
热点 key
变更导致 value 失效时，
Hermes-SDK
通过
etcd 集群
广播事件，异步失效业务应用集群中其他节点的本地缓存，保证
集群最终一致
；
热点发现
整体流程
TMC 热点发现流程分为四步：
-
数据收集
：收集
Hermes-SDK
上报的 key 访问事件；
-
热度滑窗
：对 App 的每个 Key，维护一个时间轮，记录基于当前时刻滑窗的访问热度；
-
热度汇聚
：对 App 的所有 Key，以 的形式进行 热度排序汇总；
数据收集
Hermes-SDK
通过本地
rsyslog
将
key 访问事件
以协议格式放入
kafka
，
Hermes 服务端集群
的每个节点消费 kafka 消息，实时获取
key 访问事件
。
访问事件协议格式如下：
-
appName：集群节点所属业务应用
-
uniqueKey：业务应用 key 访问事件 的 key
-
sendTime：业务应用 key 访问事件 的发生时间
-
weight：业务应用 key 访问事件 的访问权值
Hermes 服务端集群
节点将收集到的
key 访问事件
存储在本地内存中，内存数据结构为
Map
>
，对应业务含义映射为
Map
>
。
热度滑窗
时间滑窗
Hermes 服务端集群
节点，对每个 App 的每个 key，维护了一个
时间轮
：
映射任务
Hermes 服务端集群
节点，对每个 App 每 3 秒 生成一个
映射任务
，交由节点内 “缓存映射线程池” 执行。
映射任务
内容如下：
-
对当前 App，从
Map
< appname,map<="" code="">中取出 appName 对应的 Map
Map
>
；
-
遍历
Map
>
中的 key，对每个 key 取出其热度存入其
时间轮
对应的时间片中；
热度汇聚
完成第二步“热度滑窗”后，
映射任务
继续对当前 App 进行“热度汇聚”工作：
-
遍历 App 的 key，将每个 key 的
时间轮
热度进行汇总（即 30 秒时间窗口内总热度）得到探测时刻
滑窗总热度
；
-
将
< key , 滑窗总热度 >
以排序集合的方式存入 Redis 存储服务 中，即
热度汇聚结果
；
热点探测
