1. 热Key问题概述
1.1 什么是热Key
在Redis分布式缓存与消息队列场景中，热Key（Hot Key）是指在一段时间内被极高频率访问的单个或少量Redis键。这些键的访问量远超集群中其他键的平均水平，形成明显的访问热点。
热Key的本质是流量在键空间上的极度不均匀分布。当某个键的每秒请求数（QPS）达到数万甚至数十万级别时，即使Redis单实例性能优异，也会面临严重的资源竞争和延迟抖动。
热Key判定参考阈值（生产环境经验值）：
- 单Key QPS > 集群单节点总QPS的30%
- 单Key访问频次 > 10,000次/秒（普通业务）
- 单Key访问频次 > 50,000次/秒（高并发业务）
- 单Key占用带宽 > 集群节点总带宽的20%
1.2 热Key产生的业务场景
热Key并非偶然出现，它通常与特定的业务模式和数据访问特征强相关。以下是消息队列与缓存场景中最常见的六类热Key产生场景：
| 场景类别 | 典型业务示例 | 热Key特征 | 出现频率 |
|---|---|---|---|
| 秒杀/抢购 | 商品库存Key、秒杀令牌Key | 单Key瞬间QPS飙升，读写比例极高 | ★★★★★ |
| 热点新闻/内容 | 爆款文章阅读量Key、热搜榜单Key | 大量用户同时读取同一Key | ★★★★☆ |
| 全局计数器 | 全局ID生成器、日活用户统计Key | 持续高频写入，单Key竞争激烈 | ★★★★☆ |
| 消息队列去重 | 消息去重Set、任务幂等性校验Key | 大量消息同时校验同一去重Key | ★★★★☆ |
| 用户会话集中 | 大V/网红用户Session Key | 单个用户Token被海量请求携带 | ★★★☆☆ |
| 配置/规则缓存 | 全局开关Key、风控规则Key | 所有请求都读取同一配置Key | ★★★☆☆ |
实战经验：在消息队列场景中，任务去重Key是最容易被忽视的热Key来源。当大量重复消息同时到达时，所有消费者都会对同一个去重Key执行SISMEMBER或SETNX操作，瞬间将单Key QPS推高到集群无法承受的水平。
1.3 热Key对Redis集群的危害
热Key一旦形成，会对Redis集群造成连锁性、扩散性的危害。根据实际生产事故复盘，热Key的危害可以归纳为以下四个层面：
- 单节点CPU过载：Redis是单线程模型，热Key的高频访问会耗尽单个CPU核心，导致该节点上所有其他Key的请求排队等待，延迟从毫秒级飙升到秒级。
- 网络带宽打满：热Key的响应数据即使只有1KB，10万QPS也会产生约800Mbps的出口带宽，轻易打满千兆网卡，造成整个节点网络阻塞。
- 集群倾斜与雪崩：热Key所在节点资源耗尽后，该节点上的其他Key请求超时重试，重试流量进一步压向集群，可能引发级联故障和集群雪崩。
- 数据一致性与可靠性受损：主节点过热时，主从同步延迟增大，从节点数据滞后；极端情况下主节点OOM或宕机，导致数据丢失和集群不可用。
⚠ 生产事故警示：某电商平台在双十一大促期间，一个商品库存Key因秒杀流量达到18万QPS，导致该Key所在Redis节点CPU使用率飙升至98%，主从同步延迟超过30秒。最终该节点OOM宕机，触发集群主从切换失败，造成全站商品查询不可用长达12分钟。事后复盘发现，该热Key的QPS是集群平均Key QPS的900倍。
1.4 热Key治理的必要性
从上述危害可以看出，热Key治理不是锦上添花的优化，而是保障Redis集群高可用的必修课。在消息队列场景中，热Key治理尤其关键，因为：
- 消息去重Key天然具有高并发特征：大量消费者同时校验同一批消息的去重状态
- 消息队列的流量具有突发性：业务高峰期的消息洪峰会瞬间放大热Key问题
- 去重失败的业务后果严重：热Key导致去重校验超时，可能引发消息重复消费或数据不一致