热点Key问题剖析

热点Key是分布式缓存与消息队列系统中一类极具破坏力的流量异常现象。当某个Key在极短时间内被海量请求并发访问，远超单节点处理能力时，就会形成“热点”。本章从产生原因、典型场景与系统风险三个维度进行深度剖析。

2.1 热点Key的产生原因

热点Key的本质是流量在数据层面的极度不均匀分布。其产生原因可归纳为以下四类：

2.2 典型业务场景

以下三个场景是热点Key的“高发区”，每个场景都有不同的流量特征与冲击模式。

场景一：秒杀活动

• Key特征： 单个商品ID（如 seckill:item:10001）
• 流量特征： 百万级并发集中在开售前几秒，QPS瞬间飙升1000倍以上
• 冲击对象： Redis单分片、Nginx、应用服务器线程池
• 典型现象： Redis CPU 100%、连接超时、库存扣减不一致

场景二：大V发帖

• Key特征： 大V的粉丝列表Key（如 fans:uid:888888）或动态Feed Key
• 流量特征： 发帖后数分钟内，千万级粉丝拉取Feed，读请求集中爆发
• 冲击对象： Redis读分片、CDN回源、数据库
• 典型现象： 粉丝列表读取超时、Feed推送延迟、DB连接池耗尽

场景三：热搜话题

• Key特征： 热搜榜单Key（如 hot:search:list）或单个话题Key
• 流量特征： 全网用户同时刷新，读写比例可达100:1，持续数小时
• 冲击对象： Redis集群、搜索引擎、消息队列
• 典型现象： 热搜榜单更新延迟、搜索服务降级、MQ消息堆积

2.3 热点Key带来的系统风险

热点Key一旦形成，会像“多米诺骨牌”一样引发连锁故障。以下是四个核心风险维度：

1. Redis单分片过载： Redis集群中单个分片CPU飙升至100%，导致该分片上的所有Key（包括非热点Key）响应变慢或超时，引发“一人感冒全家吃药”的效应。
2. 缓存击穿与雪崩： 热点Key过期瞬间，大量请求同时穿透到数据库。数据库单行记录被并发写/读，极易触发行锁竞争或连接池耗尽。
3. 网络带宽打满： 热点Key的value如果较大（如大V的粉丝列表JSON），海量GET请求会迅速打满Redis所在服务器的网卡带宽，导致集群内其他节点通信受阻。
4. 业务一致性受损： 在秒杀等写密集型场景下，热点Key的并发写操作可能导致库存扣减不一致、超卖、重复下单等严重业务事故。

2.4 热点Key的识别与监控

在治理热点Key之前，必须先建立有效的识别与监控体系。以下是生产环境中常用的四种手段：

2.5 本章小结

热点Key是分布式系统中最常见也最危险的“隐形杀手”。它源于业务突发、数据倾斜、缓存失效或代码缺陷，在秒杀、大V发帖、热搜等场景中频繁出现。一旦形成，会引发Redis单分片过载、缓存击穿、带宽打满、数据不一致等连锁风险。建立有效的识别与监控体系（代理层全量统计 + 客户端概率采样）是后续削峰治理的前提。