by shihang.mai

1. 热点key危害

在突发情况下、短时间内出现大量请求同时访问redis的某些特定的key。

1. 大量的访问请求瞬时请求到指定的一台或多台(主从节点的情况下)redis服务器上，占据大量带宽的同时，也给redis服务器带来了较大的压力。严重的情况下，redis服务器可能会无法承受访问请求压力导致缓存服务器响应缓慢甚至宕机。

2. 这时候所有的请求都会直接去访问数据库，缓存服务器都无法承受住请求压力，数据库可想而知，导致线上数据库无法响应而宕机，最终所有服务都无法响应，产生严重的线上事故

2. TMC方案解决热点key

前提：首先西藏有服务器大概20W+，每台物理机平均虚拟60+。当虚拟机down掉或者恢复都会向我们发送告警/恢复。我们的redis服务适用cluster模式，节点有16个实例

严重事故：当时西藏地震，全部机器down掉，大量的告警向我们系统推，导致我们缓存节点压力过大崩了，然后请求到库，也把库弄崩了。直接导致系统完全崩了。

临时解决: 让服务器厂商+vmware做到在恢复期间不向我们推告警，恢复正常后重新向我们推告警。我们重启服务。

我们参考有赞的透明多级缓存TMC方案，去解决这个热点key问题。

主要要做的自动发现热点并将热点缓存访问请求前置在应用层本地缓存 。

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

  见下面的热点key分析

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

  只有热点key会存在本地缓存，其他都只会放在cluster redis集群.失效时，先失效本地缓存做强一致性，再通过etcd异步到其他本地缓存，做最终一致性

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

  我们项目用的jedis，在JedisPool初始化过程中集成TMC“热点发现”+“本地缓存”功能Hermes-SDK包的初始化逻辑，使Jedis客户端与redis交互时先与Hermes-SDK交互，从而完成 “热点探测”+“本地缓存”功能的透明接入。只需换一个jedis包即可

过程

yjhaJP.png

1. key获取

   查看图中黑线。java应用程序通过jedis获取key值时，先看该key是不是hot key，如果不是hot key，那么直接请求cluster redis集群。如果是hot key，直接从本地缓存获取值返回。并且每次获取key，都会通过通讯模块将"key访问事件"异步上传到"hot key计算服务集群"

2. 热点key同步

   查看图中蓝线。Hot key服务集群每隔一个周期(3)秒分析计算出hot key,然后通过etcd/zookeeper通过通讯模块，通知所有java集群的本地缓存模块hot key.

3. key失效

   查看图中红线。java应用程序通过jedis失效key时,看key是否是hot key，如果不是，那么直接失效cluster redis中的key.如果是hot key,那么直接失效本地缓存.然后通过通信模块，将"key失效事件"通过etcd/zookeeper，再通知其他java集群中的本地缓存失效

热点key分析

会经历数据收集-热度滑窗-热度汇聚-热点探测

数据收集

“key访问事件”协议格式如下：

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

Hot key计算服务集群会将数据保存在本地Map<String, Map<String, LongAdder，对应业务含义映射为Map< appName , Map< key , 热度

热度滑窗

Hot key计算服务集群会对每个app的每个key维护一个时间轮

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

Hot key计算服务集群每3秒对每个app会生成一个task，交给“缓存映射线程池”执行，它执行的内容是

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

热度汇聚

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

热点探测

Hot key计算服务集群中的“热点探测”节点，对每个 App ，只需周期性从其最近一份 热度汇聚结果 中取出达到热度阈值的 TopN 的 key 列表，即可得到本次探测的 热点key列表

https://segmentfault.com/a/1190000017142556#articleHeader4