4. 热点Key的常见危害

热点Key（Hot Key）是指在一段时间内，被大量并发请求集中访问的Redis Key。当业务流量激增或设计不合理时，热点Key会从多个维度冲击Redis集群乃至整个后端系统。理解其危害是进行有效削峰的前提。

4.1 四大核心危害概览

热点Key的危害并非孤立出现，它们往往相互关联、级联放大。下表总结了四种主要危害及其典型表现：

4.2 危害一：缓存击穿

缓存击穿特指单个热点Key在缓存中过期失效的瞬间，大量并发请求同时发现缓存不存在，从而直接穿透到后端数据库（DB）查询数据。由于是单个Key，对DB的冲击是瞬间且集中的。

• 触发条件：热点Key设置了过期时间，且在该Key失效的精确时刻有大量请求涌入。
• 后果：DB连接池瞬间被占满，导致正常请求也超时；严重时可能引发DB宕机。
• 典型场景：秒杀商品详情页、微博热搜榜刷新瞬间。

4.3 危害二：缓存雪崩

缓存雪崩是缓存击穿的大规模版本。它指在某一时刻，大量Key同时过期，或者Redis实例整体宕机，导致海量请求直接压向后端DB。

• 与击穿的区别：击穿是“单点”失效，雪崩是“面”或“集群”失效。
• 常见诱因：
  1. 批量Key设置了相同的过期时间（如统一凌晨过期）。
  2. Redis节点宕机或发生主从切换导致缓存清空。
  3. 缓存服务被流量冲垮后重启，缓存中无数据。
• 后果：DB瞬间承受数倍于平时的流量，极易导致数据库崩溃，引发整个服务链路的雪崩。

4.3 危害三：Redis实例CPU飙高

Redis是单线程模型（针对命令执行），一个热点Key的高频访问会耗尽单个CPU核心。即使Redis 6.0+引入了IO多线程，但核心命令处理仍是单线程。

• 原因：单Key的读写操作（尤其是复杂命令如 HGETALL、SMEMBERS、ZRANGE）需要消耗大量CPU时间片。当请求量超过单核处理极限时，CPU使用率飙升至100%。
• 表现：Redis响应延迟从微秒级飙升到毫秒甚至秒级；客户端出现大量连接超时；INFO CPU 命令显示 used_cpu_sys 和 used_cpu_user 极高。
• 诊断命令：使用 redis-cli --hotkeys 或 MONITOR 命令（生产慎用）定位热点Key。

# 使用 --hotkeys 参数扫描热点Key（Redis 4.0+）
redis-cli --hotkeys

# 输出示例（部分）
# -------- summary -------
# Sampled 100000 keys in the keyspace!
# Top 1 hot keys found:
# 1) "product:9527:detail"  - 访问频率: 15234 次/秒

4.4 危害四：网卡打满

当热点Key的Value值很大（例如存储了完整的商品详情JSON，大小超过10KB），或者请求QPS极高时，网络带宽会成为新的瓶颈。

• 大Key问题：一个10KB的Value，在10万QPS下，单节点出网带宽需求约为 10KB * 10万 = 1GB/s。普通千兆网卡（约125MB/s）会瞬间被打满。
• 小Key高并发：即使Value很小（如100字节），在百万级QPS下，带宽需求也高达 100B * 100万 = 100MB/s，同样可能打满万兆网卡。
• 后果：网络丢包、TCP重传、客户端响应变慢，甚至引发集群节点间心跳超时，导致节点被标记为下线。

4.5 危害五：集群倾斜

在Redis Cluster或Proxy分片集群中，数据按哈希槽分布到不同节点。热点Key必然落在某一个分片上，导致该分片节点的CPU、内存、网络带宽远高于其他节点。

• 表现：集群中某个节点成为“热节点”，其负载是其他节点的数倍甚至数十倍。其他节点资源闲置，整体集群吞吐量受限于最忙的节点。
• 后果：集群扩容无法线性提升性能；热节点故障时，该分片的数据全部不可用，影响范围扩大。
• 监控指标：通过 CLUSTER INFO 查看各节点 keys 和 used_memory 分布；通过 CLUSTER NODES 查看槽位分布。

4.6 危害关联与级联效应

上述五种危害并非独立存在，它们常常形成恶性循环。下面的SVG图展示了热点Key如何从单点问题演变为系统级灾难：

4.7 危害总结与应对思路

热点Key的危害具有隐蔽性（平时不出现，高并发时才暴露）和破坏性（单点故障引发全局雪崩）。在后续章节中，我们将针对每种危害给出具体的削峰策略：