1. 客户端

在客户端统计所访问 key 的频率.

2. 代理端

像 Twemproxy、Codis 这些基于代理的 Redis 分布式架构, 所有客户端的请求都是通过代理端完成的。此架构是最适合做热点 key 统计的, 因为代理是所有 Redis 客户端和服务端的桥梁。但并不是所有 Redis 都是采用此种架构。

image.png

3. Redis 服务端

monitor 命令可以监控到 Redis 执行的所有命令, 下面为一次 monitor 命令执行后部分结果:

  • 一段时间内的热点 key 排行榜, 命令排行榜, 客户端分布

image.png

  • monitor 命令在高并发条件下, 会存在内存暴增和影响 Redis 性能的隐患, 所以此种方法适合在短时间内使用
  • 只能统计一个 Redis 节点的热点 key, 对于 Redis 集群需要进行汇总统计

4. 机器

如果站在机器的角度, 可以通过对机器上所有 Redis 端口的 TCP 数据包进行抓取完成热点 key 的统计.

image.png

表12-5 寻找热点 key 的四种方案
image.png

解决热点 key 问题的三种方案

  1. 拆分复杂数据结构: 如果当前 key 的类型是一个二级数据结构, 例如哈希类型。如果该哈希元素个数较多, 可以考虑将当前 hash 进行拆分, 这样该热点 key 可以拆分为若干个新的 key 分布到不同 Redis 节点上, 从而减轻压力。
  2. 迁移热点 key: 以 Redis Cluster 为例, 可以将热点 key 所在的 slot 单独迁移到一个新的 Redis 节点上, 但此操作会增加运维成本
  3. 本地缓存加通知机制: 可以将热点 key 放在业务端的本地缓存中, 因为是在业务端的本地内存中, 处理能力要高出 Redis 数十倍, 但当数据更新时, 此种模式会造成各个业务端和 Redis 数据不一致, 通常会使用发布订阅机制来解决类似问题