incident-redis-hotkey

一次促销配置热 Key 打满 Redis Cluster 单分片的复盘（匿名化合成案例）。

现象

某业务集群使用 Redis Cluster 缓存活动配置。活动开始后，部分接口的 p99 延迟从几十毫秒升到数秒，并出现连接超时和重试。Redis 集群总 CPU 看起来只有三成左右，但其中一个主节点的单核 CPU 已接近 100%；同一分片上的其他 key 也开始变慢，其他分片仍然平稳。内存、网络和集群状态没有明显异常。

时间线

• T+0：活动流量进入，活动配置的 TTL 恰好在同一时刻到期，大量请求同时 miss，应用开始出现 Redis 超时，监控告警只显示“p99 升高”。
• T+3m：查看分片指标，确认只有一个主节点 CPU 打满，其余分片低于三成；聚合 CPU 掩盖了热点。
• T+6m：先怀疑大 key、慢命令或网络问题。--bigkeys 没有发现异常，SLOWLOG 也几乎是空的，但请求仍在排队。
• T+9m：应用链路追踪显示，大部分慢请求都在读取同一个活动配置 key，而不是随机分布。CLUSTER KEYSLOT 确认该 key 落在过热分片。
• T+12m：回看应用指标，确认多个实例在同一秒过期后没有请求合并，回源和回填持续放大单分片压力。
• T+15m：临时给该只读配置加 1 秒本地缓存和请求合并，超时开始下降。
• T+20m：分片 CPU 回到可控范围，接口恢复，但该 key 仍只能落在一个槽位。
• T+26m：把只读配置复制成多个带后缀的子 key，客户端随机读取；后续发布改用后台刷新和随机 TTL。
• T+32m：观察多个流量高峰，单分片不再打满，事件关闭。

影响面

受影响的不只是活动配置接口。哈希槽落在该分片上的其他 key 也共享同一个事件循环，因此一些无关业务出现了延迟升高和超时。客户端重试又放大了流量，形成短时拥塞。没有数据丢失或主从切换，但部分请求在 HTTP 层返回超时，用户侧表现为页面加载慢或重试。

误导线索

第一个误导信号是集群聚合 CPU。整体只有三成，很容易让人认为 Redis 还有大量余量，于是转向排查网络和客户端。真正有意义的指标是每个主节点的 CPU、事件循环延迟和该节点上的命令耗时；一个 Cluster 有多个分片，不代表负载会自动均摊，一个 key 永远只属于一个哈希槽和一个主节点。

第二个误导信号是空的 SLOWLOG。慢日志记录的是命令执行时间，不包含命令在 socket 和事件循环队列里等待的时间。单次 GET 本身很快，但当分片被打满后，请求会先在队列中排队，客户端看到的是整体延迟和超时，慢日志却可能没有任何记录。MEMORY USAGE 也证明这个 key 并不大，推翻了“大 key 导致阻塞”的假设。最后是应用维度和 CLUSTER KEYSLOT 的证据把问题锁定到单一热 key。

根因

活动配置是一个读多写少、访问极度集中的 key。它所在的槽位只能由一个主节点处理，而 Redis 执行命令的主线程是单线程模型，单核被打满后，同一分片上的所有请求都要排队。配置统一过期、应用没有本地缓存和 singleflight，导致大量并发 miss 同时回源并回填；活动流量和客户端重试叠加，最终把一个普通小 key 变成了热点。

这不是“集群容量不足”的平均问题，也不是大 key 或慢命令问题。增加分片数量不会自动拆散一个 key，重新分片也只能迁移整个槽位，仍然只有一个主节点承接该 key 的读写。

修复

先降低放大效应，再处理 key 的分布。确认该配置短暂陈旧可接受后，在应用侧增加带随机抖动的短 TTL 本地缓存，并对同 key 的 miss 做请求合并，避免所有实例同时回源。给客户端设置明确超时、限制重试次数并加入退避和抖动，防止重试风暴继续打满分片。

定位和验证命令如下：

redis-cli --cluster call <host>:<port> INFO cpu
redis-cli --cluster call <host>:<port> INFO commandstats
redis-cli --cluster check <host>:<port>
redis-cli -c -h <host> -p <port> CLUSTER KEYSLOT <key>
redis-cli -c -h <host> -p <port> CLUSTER NODES
redis-cli -c -h <host> -p <port> SLOWLOG GET 20
redis-cli -h <host> -p <port> CONFIG GET maxmemory-policy

只有确认淘汰策略为 LFU 时，才在对应主节点上使用 redis-cli --hotkeys；它会扫描 key，本身也有开销，不要在高负载时反复执行。MONITOR 更不适合直接开在高 QPS 主节点上，必须采样时应在低峰、限时并设置超时，优先使用应用侧埋点和代理日志。

长期修复根据读写性质选择：

• 只读配置拆成多个带后缀的副本 key，客户端随机选一个读取；发布时更新全部副本，并保留版本号或宽限期。
• 有写入的计数器或状态不要简单随机读；应按业务维度拆 key，或使用本地聚合后再合并。
• 统一过期改为后台刷新加随机 TTL，避免所有实例在同一秒失效。
• 增加只读副本可以分担部分读流量，但需要客户端或代理显式支持读路由，还要接受复制延迟，不能把它当成透明扩容。
• 临时纵向扩容只能争取时间，无法改变单 key 落单分片的事实。

预防

• 监控不能只看集群平均值。至少按主节点看 CPU、命令延迟、连接数，并观察同分片其他 key 的受影响情况。
• 对大促、热点商品、活动开关等可预期的热点做容量模型，按单 key 峰值而不是集群总 QPS 估算。
• 在应用层默认采用 singleflight、本地缓存、TTL 抖动和重试预算；热点读取不应依赖 Redis 单点硬扛。
• 做热点专项压测：固定少数 key 打满一个分片，验证超时、重试和降级行为，而不是只测均匀随机 key。
• 定期检查 SLOWLOG、LATENCY、命令统计和 key 分布，但不要用慢日志为空来排除 Redis 侧排队。
• 预案中明确短时降级的数据一致性边界，例如哪些配置可以短暂陈旧、哪些必须强一致。

相关命令

• redis-cli — 查看分片、命令统计和 key 信息
• redis-cluster — 槽位、分片和集群操作
• redis-hotkey — 热 key 的基础排查路径
• redis-slowlog — 判断执行耗时与排队耗时
• redis-memory-full — 排除淘汰与内存压力
• top — 关联应用侧 CPU 与线程行为
• perf — 需要时分析客户端或代理开销

参考链接

• Redis 延迟排查
• Redis Cluster 规范
• Redis INFO 命令
• Redis 慢日志

读完自测

合上页面，先回答，再展开对照。

1. 为什么集群总 CPU 不高，仍可能出现 Redis 热 key 故障？
2. 慢日志为空为什么不能排除 Redis 侧延迟？
3. 增加分片或只读副本能否直接解决单个热 key？