上一节，我们聊到了 Redis 的 Bigkey，这节内容我们聊聊同样需要引起重视的 Hotkey。

1 背景

Hotkey 指某个时间段访问频率比较高的键值，对应的业务比如热点话题或者热点商品。

Hotkey 可能会导致集群流量不均衡，或者某一个节点 QPS、网卡流量被打满。

因此需要考虑一些措施来降低 Hotkey 出现的概率，比如在编码阶段避免产生 Hotkey，或者提前准备出现 Hotkey 时的应对方案。

2 Hotkey 产生原因

日常生活中，可能很多热点事件的背后，都会产生一个鲜为人知的 Hotkey。比如某某明星出轨、双十一某个热门商品的促销等等。如果不提前准备，很可能导致用户无法查看到相关评论或者买到心仪的商品。因此提前预防和优化 Hotkey 显得尤为重要。

3 怎样发现 Hotkey

Hotkey 对 Redis 实例影响这么大，那么应该怎样发现 Hotkey 呢？这里总结了几个常见做法：

3.1 客户端

比如每次调用 Redis 命令时，使用字典进行记录。或者修改 Redis SDK，记录每个请求，定期上报数据。

但这种方法存在一些问题：

• 无法预知 key 的个数，存在内存泄漏的危险。
• 只能了解当前客户端的 Hotkey。
• 多语言 SDK 对齐麻烦，维护成本高。

3.2 代理层

类似客户端收集的方式，在代理层增加 key 使用情况的收集。适用于类似 Twemproxy 或者 Codis 的架构。

3.3 使用 monitor

用法如下：

redis-cli -p 6301 monitor

如上图，会打印出所有正在执行的命令。

在 monitor 的基础上，Facebook 开源了 redis-faina[https://github.com/facebookarchive/redis-faina]，具体用法如下：

git clone https://github.com/facebookarchive/redis-faina.git
cd redis-faina/
redis-cli -p 6301 monitor |head -n 100|./redis-faina.py

但是：运行单个 monitor 客户端可能将吞吐量降低 50％ 以上（具体可以参考Redis 官方文档 monitor[https://redis.io/commands/monitor]）。

3.4 使用 hotkeys 参数获取

redis-cli -p 6301 --hotkeys

其结果示例如下：

但是：仅限于最大内存策略为 volatile-lfu 或 allkeys-lfu。实际上是通过 scan + object freq 完成的，由于需要扫描整个 keyspace，实时性上比较差，如果 key 的数量比较多，耗时可能非常长（实测：570M 数据，耗时5分30秒）。

3.5 Redis 节点抓包

Redis 客户端使用 TCP 协议与服务端进行交互，通信协议采用的是 RESP。因此可以采用对机器上 Redis 端口的 TCP 数据包进行抓取，完成Hotkey 的统计。

但是：此方法需要一定的开发成本，并且也只是以机器为单位进行统计，如果需要知道集群的Hotkey，需要进行汇总。

3.6 阿里云实例通过审计日志

如果使用的是阿里云 Redis 服务，可以通过审计日志判断出 Hotkey，文档链接：https://help.aliyun.com/document_detail/160585.html?spm=a2c4g.11186623.2.16.4c043e592Tbdlg#task-2460922

4 优化建议

那么 Hotkey 应该怎么去优化呢？这里介绍几种常用的方法：

4.1 拆分复杂的数据结构

比如当前 key 的类型是哈希类型，如果该哈希元素个数比较多，可以考虑将当前 hash 进行拆分，这样热点 key 可以拆分为多个新 key 分布到不同 Redis 节点上。

4.2 迁移热点 key

比如 Redis Cluster，可以把 Hotkey 所在的 slot 单独迁移到一个新的 Redis 节点上。当然，这种方式运维成本比较高。

4.3 本地缓存加通知机制

将 Hotkey 放在业务端的本地缓存中，然后使用发布订阅机制保证业务端本地缓存与 Redis 数据一致。

专栏《Redis 运维实战》系列文章推荐