读有赞---多级缓存方案

多级缓存的痛点：

1. 热点探测：如何快速且准确的发现热点访问key
2. 数据一致性：前置在应用层的缓存，如何保障与分布式缓存系统的数据一致性
3. 效果验证：看本地缓存命中率
4. 透明接入：减少入侵性

TMC解决方案

tmc：透明多级缓存

• 应用层热点探测
• 应用层本地缓存
• 应用层缓存命中统计

为什么需要多级缓存

• 活动时间、活动类型、活动商品之类的信息不可预期，导致 缓存热点访问 情况不可提前预知；
• 缓存热点访问 出现期间，应用层少数 *热点访问 key * 产生大量缓存访问请求：冲击分布式缓存系统，大量占据内网带宽，最终影响应用层系统稳定性；

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

整体分析

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

稳定性

• 数据上报异步化：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热点发现

• 数据收集：收集 增强sdk上报的key访问事件
• 热度滑窗：时间轮
• 热度汇集：<key,热度>的形式来进行热度排序汇总
• 热点探测：topN的key进行推送

数据收集

Hermes-SDK 通过本地rsyslog将 key访问事件 以协议格式放入 kafka ，Hermes服务端集群 的每个节点消费 kafka 消息，实时获取 key访问事件。

访问事件协议格式如下：

• appName：集群节点所属业务应用
• uniqueKey：业务应用 key访问事件 的 key
• sendTime：业务应用 key访问事件 的发生时间
• weight：业务应用 key访问事件 的访问权值

Hermes服务端集群 节点将收集到的 key访问事件 存储在本地内存中，内存数据结构为Map<String, Map<String, LongAdder>>，对应业务含义映射为Map< appName , Map< uniqueKey , 热度 >>。

热度滑窗

这一部分就是整了一个时间轮出来，然后每三秒执行一次，总共存储30秒的访问频率。

时间滑窗

Hermes服务端集群 节点，对每个App的每个 key ，维护了一个 时间轮：

• 时间轮中共10个 时间片，每个时间片记录当前 key 对应 3 秒时间周期的总访问次数；
• 时间轮10个时间片的记录累加即表示当前 key 从当前时间向前 30 秒时间窗口内的总访问次数；

映射任务

Hermes服务端集群 节点，对每个 App 每3秒 生成一个 映射任务 ，交由节点内 “缓存映射线程池” 执行。映射任务 内容如下：

• 对当前 App ，从Map< appName , Map< uniqueKey , 热度 >>中取出 appName 对应的Map Map< uniqueKey , 热度 >>；
• 遍历Map< uniqueKey , 热度 >>中的 key ，对每个 key 取出其热度存入其 时间轮 对应的时间片中；

热度汇聚

遍历整个时间轮，对每个key的三十秒的访问频率进行统计并排序

完成第二步“热度滑窗”后，映射任务 继续对当前 App 进行“热度汇聚”工作：

• 遍历 App 的 key ，将每个 key 的 时间轮 热度进行汇总（即30秒时间窗口内总热度）得到探测时刻 滑窗总热度；
• 将 < key , 滑窗总热度 > 以排序集合的方式存入 Redis存储服务 中，即 热度汇聚结果；

总体流程：

特性总结

实时性

Hermes-SDK基于rsyslog + kafka 实时上报 key访问事件。 映射任务 3秒一个周期完成“热度滑窗” + “热度汇聚”工作，当有 热点访问场景 出现时最长3秒即可探测出对应 热点key。

准确性

key 的热度汇聚结果由“基于时间轮实现的滑动窗口”汇聚得到，相对准确地反应当前及最近正在发生访问分布。

扩展性

Hermes服务端集群 节点无状态，节点数可基于 kafka 的 partition 数量横向扩展。

“热度滑窗” + “热度汇聚” 过程基于 App 数量，在单节点内多线程扩展。