1. Redis热点问题概述
1.1 什么是Redis热点Key
热点Key（Hot Key）是指在Redis集群中，某个或某几个Key在极短时间内被大量客户端并发访问，导致该Key所在节点的CPU、带宽、内存等资源被迅速耗尽，从而引发整个系统性能下降甚至雪崩的现象。
热点Key通常表现为：
- 高QPS：单个Key的每秒请求量达到数万甚至数十万级别
- 高带宽：Key对应的Value较大时，网络出口带宽被快速打满
- 高CPU：Redis单线程模型下，热点Key的密集操作阻塞事件循环
典型场景： 微博热搜榜、电商秒杀商品、直播弹幕、实时排行榜、全局计数器等业务中，热点Key的出现频率极高。
1.2 热点问题的产生原因
热点Key的产生通常由业务特征、架构设计、数据倾斜等多方面因素共同导致。以下是主要成因：
| 原因分类 | 具体描述 | 典型场景 |
|---|---|---|
| 业务突发流量 | 运营活动、突发事件导致短时间内海量用户集中访问同一资源 | 双11秒杀、微博热搜、抢红包 |
| 数据分布不均 | Key的哈希分布天然倾斜，部分Key的数据量或访问量远大于其他Key | 大V粉丝列表、全局计数器 |
| 缓存设计缺陷 | 缓存穿透、缓存击穿后，大量请求直接打到同一个Key上重建缓存 | 空值缓存、互斥锁重建 |
| 客户端配置不当 | 连接池过小、重试策略激进、未做本地缓存，导致请求集中穿透 | Jedis连接池耗尽、超时重试风暴 |
| 数据分片策略 | Redis Cluster的slot分配导致热点Key所在节点成为瓶颈 | 单节点承载80%以上流量 |
经验法则： 当单个Key的QPS超过Redis单节点处理能力的30%（约1.5万QPS，视硬件而定），就应启动热点Key的监控与治理流程。
1.3 热点问题对系统的影响
热点Key一旦形成，会从多个维度对系统造成连锁冲击，严重时可能导致整个Redis集群甚至业务系统崩溃。
热点问题对系统的具体影响可归纳为以下四个层面：
- Redis节点层面
- CPU使用率飙升至100%，Redis单线程模型下所有请求排队等待
- 内存占用异常增长，可能触发OOM或maxmemory淘汰策略
- 网络出口带宽被打满，导致TCP丢包、重传、连接超时
- 集群层面
- 热点节点成为整个集群的短板，拖慢所有涉及该slot的请求
- 主从复制延迟增大，从节点同步跟不上主节点写入
- 集群分片不均，部分节点空闲而热点节点过载
- 业务层面
- 接口响应时间从毫秒级飙升到秒级甚至超时
- 大量请求失败，触发客户端重试风暴，进一步加剧负载
- 缓存击穿后，数据库被瞬间打垮，引发全链路故障
- 运维层面
- 告警风暴：CPU、带宽、延迟、错误率同时告警
- 排查困难：热点Key往往动态出现，难以提前预判
- 扩容无效：单纯增加节点无法解决单个Key的访问集中问题
严重警告： 热点Key导致的系统雪崩往往在30秒内完成。从第一个请求超时到整个集群不可用，留给运维人员的响应窗口极短。因此，事前预防和自动熔断机制远比事后排查更重要。
1.4 热点问题的识别指标
在实际生产环境中，可以通过以下关键指标快速识别热点Key：
| 指标名称 | 正常范围 | 热点预警阈值 | 监控工具 |
|---|---|---|---|
| 单Key QPS | < 5000 | > 10000 | redis-cli --hotkeys |
| 节点CPU使用率 | < 40% | > 80% | Prometheus + redis_exporter |
| 节点网络带宽 | < 50% 上限 | > 80% 上限 | sar / iftop |
| 请求平均延迟 | < 5ms | > 50ms | Redis slowlog |
| 客户端连接数 | < 2000 | > 5000 | client list |
最佳实践： 建议在Redis客户端侧（如Jedis、Lettuce）集成热点Key自动探测逻辑，当检测到单个Key的访问频率超过阈值时，自动触发本地缓存、限流或Key拆分策略，实现秒级自愈。