Redis Cluster 分片以后，很多人会以为流量自然均摊。但只要某个 key 被极高频访问，它所在的 slot 和节点就会成为全局瓶颈。
Hot Key 的危险在于它不是容量问题，而是局部流量问题。整个集群看起来 QPS 还没到上限，单个节点却已经 CPU 打满、网络拥塞或连接堆积。
先把机制边界说清楚
这一篇讨论热点 key 的识别和防护，不把它和大 key 混成一类。Hot Key 是访问频率异常，大 key 是体积异常；两者可以叠加，但治理重点不同。
整体路径
上面这张图先把主线铺开：大量请求汇聚到一个 slot，一台节点先被打满。Hot Key 是局部流量问题不是容量问题，治理的关键是先能发现（--hotkeys/LFU/埋点），再把请求在打到 Redis 之前就分散掉。
底层机制
- Cluster 按 key 路由，热点 key 会把请求集中到一个 slot 所在节点——分片无法消化热点，因为单个 slot 锁死在一个 master 上。
- 读热点可能造成 CPU、网络和输出缓冲压力，写热点还会放大复制和持久化压力。
- 发现热点 key 的标准工具是
redis-cli --hotkeys，它基于 Redis 的 LFU 访问计数（要求maxmemory-policy设成 LFU 系策略，否则 key 没有访问频次信息可统计）；也可以用OBJECT FREQ key查单个 key 的访问频次，或在客户端/网关层做 key 维度的 TopK 埋点。发现手段要尽早——线上 CPU 单核打满时才排查就很被动。 - 治理手段包括本地缓存（短 TTL + 主动失效）、请求合并（singleflight 回源）、读副本扩散、拆 key 和限流降级。越靠近请求入口治理，效果越好。
这些机制放在一起看，就能理解 Hot Key 为什么是局部流量问题而不是容量问题——分片摊不开热点，治理必须回到请求入口或用本地缓存消化。
取舍与边界
Hot Key 没有纯 Redis 内部的万能开关。越靠近请求入口治理，效果越好；越等到 Redis 节点打满，手段越被动。
典型问题：用机制化例子排查
- 给客户端或网关加 key 维度统计，提前发现 TopK。
- 读多写少热点优先本地缓存，并设置短 TTL 和主动失效策略。
- 热点重建时用请求合并，避免所有请求同时回源。
- 写热点要考虑业务拆分或异步聚合，不要指望加从库解决写压力。
收束：一句判断
分片解决平均压力，Hot Key 负责提醒你平均值会骗人。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
