Redis 热 Key 突增时怎么止血和回查

Redis 热 Key 故障很典型：

• 业务看起来像“缓存很快”
• 但单个 key 被瞬时打爆
• 某个 Redis 分片 CPU 飙升、网络流量激增
• 上游接口 RT 抖动，甚至开始回源打数据库

这类问题最怕两件事：
一是把它当成普通 Redis 慢查询，二是只会扩容，不会先止血。

先说结论

• 热 Key 故障的核心不是 Redis 变慢，而是流量过度集中到单个 key 或单个分片
• 第一目标永远是止血: 限流、降级、热点隔离、短期本地缓存
• 第二目标才是回查根因: 为什么流量突然集中、为什么热点没有提前打散
• 根因通常在业务流量模型、缓存设计和热点预案，而不只是 Redis 参数

一个典型故障现象

以商品详情接口为例，某次大促前首页把一个爆款商品推到全站：

• 大量请求集中打到 product:detail:1001
• 对应 Redis 分片 QPS 和出口流量陡增
• 接口 RT 从 20ms 飙到 300ms
• 少量请求因超时开始回源 MySQL
• MySQL 连接数也开始上升

这时如果不及时处理，很快会从“单 key 热点”扩散成“缓存 + 数据库双抖动”。

很多真正的事故都不是 Redis 单点慢一点，而是：

• Redis 热点先抖
• 应用超时增加
• 请求开始回源数据库
• 数据库连接数和慢 SQL 一起被放大

所以这类问题的关键不是“怎么看 Redis”，而是怎么在热点扩散前先止血。

第一阶段: 先止血

1. 限流

对热点接口、热点商品、热点用户维度做临时限流。
目的是先把进入应用层和 Redis 的总流量压下来。

2. 本地缓存兜一层

如果热点数据变化不频繁，可以在应用实例内临时加短 TTL 本地缓存，比如 1 到 3 秒。
这样很多重复请求不用都打到 Redis。

3. 降级非核心字段

商品详情页里如果有推荐、评论摘要、运营标记等非核心信息，可以先降级，减少一次请求内的 Redis 次数。

4. 必要时热点隔离

极端情况下，可以把这个热点 key 单独拆出来：

• 复制到独立 key
• 放到独立实例
• 或单独走专门热点服务

5. 控制回源

如果 Redis 已经开始抖动，要优先确认回源策略是不是会瞬间把请求全部打到 MySQL、ES 或远程接口。

很多系统真正崩不是因为 Redis 顶不住，而是因为回源链路没有被保护住。

第二阶段: 确认是不是热 Key

常见观察信号：

• 单个 Redis 节点 QPS、CPU、网络显著高于其他节点
• 业务侧集中访问少量固定 key
• 热点接口 RT 抖动和 Redis 节点抖动高度同步

排查时可以结合：

• 应用日志里的 key 访问分布
• Redis 慢日志和监控
• 节点级命令统计
• 接口维度的 top 参数

注意，热 Key 不一定会出现在慢日志里，因为单次命令可能很快，只是频率过高。

这点特别容易误导人：

• 慢日志里没问题
• 不代表热点没问题

热点问题本质是“频率异常高”，不是“单次执行特别慢”。

第三阶段: 回查根因

热 Key 常见根因通常是下面几类。

1. 热点流量天然集中

比如爆款商品、首页配置、热门活动、统一配置开关。
这些 key 天生容易热。

2. 缓存设计没有做打散

例如一个超热点配置全部实例都查同一个 key，没有：

• 本地缓存
• 多副本 key
• 热点分桶

3. 上游场景发生变化

大促、运营推荐、推送消息、短视频带货、站外导流，都会把热点突然放大。

4. 回源策略过于脆弱

Redis 一旦抖动，请求立刻打 MySQL，导致问题扩散成缓存击穿。

5. 热点被放大但没有预热

运营活动、推荐位切换、消息推送、短视频导流，这些都可能把某个 key 的访问量在很短时间里放大很多倍。

热 Key 和大 Key 不要混淆

两者经常一起出现，但不是一回事：

• 热 Key: 访问频率异常高
• 大 Key: 单个 key 数据体积异常大

一个 key 可能又热又大，那会更糟：

• 每次读取都重
• 频率还高

排障时要分清楚是频率问题、体积问题，还是两者叠加。

一套更实用的长期治理方案

1. 建热点识别机制

对高频 key、热点接口参数、单节点 QPS 差异做监控告警。

2. 热点分级

把 key 分成：

• 常规热点
• 可预期大促热点
• 突发异常热点

不同等级对应不同预案。

3. 设计多级缓存

对特别热点的数据，常见方案是：

• 本地缓存
• Redis
• 必要时独立热点缓存服务

4. 做流量预热

大促前提前加载热点数据、预建本地缓存、预热网关限流规则。

5. 给热点回源链路加明确边界

包括：

• 单 key 回源限流
• 单机本地缓存兜底
• 熔断与快速失败
• 请求合并

这类问题里最常见的误区

1. 只想着扩 Redis

扩容能缓解，但如果热点仍然落在同一个分片规则上，问题不一定解决。

2. 发现热点后直接删 key

如果没有更稳的兜底策略，删 key 往往会引发更严重的回源风暴。

3. 没有把业务事件和热点关联起来

很多热 Key 问题其实是运营动作触发的。
技术侧如果只看 Redis 指标，不看业务活动，很容易找不到真正原因。

一个现场处理清单

当你在线上怀疑出现热 Key 时，可以先按这条顺序处理：

1. 确认受影响接口和 key 范围
2. 先限流和降级，避免问题扩散
3. 对超热点数据补本地缓存或临时隔离
4. 看是否有回源压力同步上升
5. 复盘流量来源和缓存设计缺口

如果再细一点，我会补两步：

6. 确认是不是只有一个分片明显异常。
7. 看热点是否和某次活动、推送、推荐位变更时间点吻合。

总结

Redis 热 Key 故障的核心，不是单机性能调优，而是热点流量治理。
真正成熟的做法是：

• 先止血
• 再定位热点来源
• 最后改缓存分层和业务预案

这样下次再遇到爆款流量，系统才不会又被同一个点打穿。真正要治理的不是 Redis 参数，而是热点流量如何被识别、缓冲、隔离和兜底。