redis热点key解决方案_闲谈如何处理redis热点key问题

热点key

比如在双11的时候有一些非常火爆的商品，用户同时抢购这些商品。这时就会有十几万甚至甚至更大的请求去访问redis上的某个特定key。

大量的请求会造成流量过于集中，达到例如Redis单实例瓶颈（一般是10W QPS级别），或者物理网卡上限，从而导致这台redis的服务器Hold不住，甚至压垮整个缓存服务。

发现热点key

预估

针对业务提前预估出访问频繁的热点key，例如秒杀商品业务中，秒杀的商品都是热点key。

当然并非所有的业务都容易预估出热点key，可能出现漏掉或者预估错误的情况。

客户端嵌入代码

在访问redis客户端之前加入一行代码进行数据统计，统计方式多种多样，有本地计数、发消息单独处理统计等。

但是这种方式会对客户端代码造成入侵。

在Proxy（代理层）收集

proxy层统一入口做统计，对业务代码无入侵。

redis命令

monitor命令可以实时抓取出redis服务器接收到的命令，然后写代码统计出热key。也可以通过redis-faina实现。但是该命令在高并发的条件下，不仅有内存暴增的隐患，还会降低redis的性能。

redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可，操作方便。该参数在执行的时候，如果key比较多，执行起来比较慢

日志采集分析

将日志通过agent采集，将采集的日志进行分析，对业务代码无入侵。

解决方案

发现热点key之后，需要对热点key进行处理。

使用二级缓存

可以使用 guava-cache或hcache，发现热点key之后，将这些热点key加载到JVM中作为本地缓存。访问这些key时直接从本地缓存获取即可，不会直接访问到redis层了，有效的保护了缓存服务器。

备份（不建议）

把热点key在多个redis上都存一份，当有热key请求进来的时候，在redis中随机选取一台，进行访问取值，返回数据。

但是这种情况维护代价非常大，假设有100个备份KEY，那么在删除或者更新时，也需要更新100个KEY，所以这种方案不是很推荐。

有赞透明多级缓存解决方案（TMC）

TMC 即透明多级缓存（ Transparent Multilevel Cache ），是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。

​

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

• 存储层：提供基础的kv数据存储能力，针对不同的业务场景选用不同的存储服务（ codis / zankv / aerospike ）；
• 代理层：为应用层提供统一的缓存使用入口及通信协议，承担分布式数据水平切分后的路由功能转发工作；
• 应用层：提供统一客户端给应用服务使用，内置“热点探测”、“本地缓存”等功能，对业务透明；

稳定性

数据上报异步化：Hermes-SDK 使用rsyslog技术对“ key 访问事件”进行异步化上报，不会阻塞业务

通信模块线程隔离：Hermes-SDK 的 通信模块 使用独立线程池+有界队列，保证事件上报&监听的I/O操作与业务执行线程隔离，即使出现非预期性异常也不会影响基本业务功能

缓存管控：Hermes-SDK 的 热点模块 对本地缓存大小上限进行了管控，使其占用内存不超过 64MB（LRU），杜绝 JVM 堆内存溢出的可能

一致性

Hermes-SDK 的热点模块仅缓存 热点key 数据，绝大多数非热点key数据由缓存集群存储

热点key 变更导致 value 失效时，Hermes-SDK 同步失效本地缓存，保证本地强一致

热点key 变更导致 value 失效时，Hermes-SDK 通过 etcd集群 广播事件，异步失效业务应用集群中其他节点的本地缓存，保证 集群最终一致

实现方案

TMC 本地缓存

TMC 本地缓存整体结构分为如下模块：

• Jedis-Client： Java 应用与缓存服务端交互的直接入口，接口定义与原生 Jedis-Client 无异；
• Hermes-SDK：自研“热点发现+本地缓存”功能的SDK封装， Jedis-Client 通过与它交互来集成相应能力；
• Hermes服务端集群：接收 Hermes-SDK 上报的缓存访问数据，进行热点探测，将热点 key 推送给 Hermes-SDK 做本地缓存；
• 缓存集群：由代理层和存储层组成，为应用客户端提供统一的分布式缓存服务入口；
• 基础组件： etcd 集群、 Apollo 配置中心，为 TMC 提供“集群推送”和“统一配置”能力；

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

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

TMC基本流程

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服务端集群 ，以便其根据上报数据进行“热点探测”

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 值失效，以达到集群数据最终一致

热点发现

Hermes服务端集群 不断收集 Hermes-SDK上报的key访问事件，对不同业务应用集群的缓存访问数据进行周期性（3s一次）分析计算，以探测业务应用集群中的热点key列表

对于探测到的热点key列表，Hermes服务端集群 将其通过 etcd集群 推送给不同业务应用集群的 Hermes-SDK 通信模块，通知其对热点key列表进行本地缓存

配置读取

Hermes-SDK 在启动及运行过程中，会从 Apollo配置中心 读取其关心的配置信息（如：启动关闭配置、黑白名单配置、etcd地址...）

Hermes服务端集群 在启动及运行过程中，会从 Apollo配置中心 读取其关心的配置信息（如：业务应用列表、热点阈值配置、 etcd 地址...）

TMC热点发现

TMC 热点发现流程分为四步：

数据收集

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

热度滑窗

Hermes服务端集群节点，对 App 的每个 Key ，维护一个时间轮，记录基于当前时刻滑窗的访问热度。

时间轮中共10个时间片，每个时间片记录当前 key 对应 3 秒时间周期的总访问次数。

时间轮10个时间片的记录累加即表示当前 key 从当前时间向前 30 秒时间窗口内的总访问次数。

热度汇聚

对 App 的所有 Key ，以<key,热度>的形式进行 热度排序汇总。

Hermes服务端集群节点，对每个 App 每3秒生成一个 映射任务 ，交由节点内 “缓存映射线程池” 执行。将数据收集来的数据取出其热度存入其 时间轮 对应的时间片中。

然后遍历 App 的 key ，将每个 key 的 时间轮 热度进行汇总（即30秒时间窗口内总热度）得到探测时刻滑窗总热度。

将 < key , 滑窗总热度 > 以排序集合的方式存入 Redis存储服务 中，即热度汇聚结果；

热点探测

对 App ，从 热Key排序汇总结果中选出 TopN的热点Key ，推送给 Hermes-SDK。