2. Redis 热点Key定义
在Redis生产环境中，热点Key是指那些在短时间内被大量并发请求集中访问的Key。这类Key会引发单节点CPU飙升、网络带宽打满、甚至整个Redis集群雪崩。理解热点Key的定义、判定标准和常见类型，是后续实施分桶策略的前提。
2.1 什么是热点Key
热点Key并非Redis官方术语，而是运维实践中对访问频率远超平均水平的Key的统称。当某个Key的QPS（每秒查询数）达到单节点处理能力的30%以上时，即可视为热点。热点Key通常具有以下特征：
- 集中性：大量客户端同时读写同一个Key
- 突发性：流量在短时间内急剧上升，峰值可达正常值的10~100倍
- 单点瓶颈：即使Redis集群有多个分片，热点Key也只落在一个节点上
典型案例：某电商大促期间，商品详情页的缓存Key "product:10001" 在1秒内被50万个请求同时读取，导致该Redis节点CPU使用率从20%飙升至95%，响应延迟从1ms恶化到500ms。
2.2 热点Key的判定标准
判定一个Key是否为热点，不能仅凭直觉，需要结合量化指标和监控工具。以下是业界通用的判定标准：
| 判定维度 | 指标名称 | 阈值参考 | 说明 |
|---|---|---|---|
| 访问频率 | QPS（每秒查询数） | > 10,000 次/秒 | 单Key QPS超过节点总QPS的30% |
| 带宽占用 | 网络吞吐量 | > 50 MB/s | 单Key响应数据量大时尤其明显 |
| CPU消耗 | 单节点CPU使用率 | > 60% | 热点Key导致节点CPU异常偏高 |
| 延迟变化 | P99延迟 | > 100ms | 正常延迟的5倍以上 |
| 连接数 | 客户端连接数 | > 500 | 大量连接同时操作同一Key |
监控工具推荐：使用
redis-cli --hotkeys 命令扫描热点Key；或通过 MONITOR 命令采样分析；生产环境建议集成Redis Exporter + Prometheus + Grafana 实现实时监控。
2.3 常见热点Key类型
根据业务场景的不同，热点Key可以分为以下几类。了解这些类型有助于提前识别和预防：
| 类型 | 典型Key模式 | 业务场景 | 风险等级 |
|---|---|---|---|
| 爆款商品 | product:{id} |
秒杀、大促、限时抢购 | ★★★★★ |
| 热门新闻/视频 | news:{id} / video:{id} |
热搜榜单、推荐流 | ★★★★☆ |
| 全局计数器 | counter:total_visits |
PV/UV统计、点赞数 | ★★★★☆ |
| 用户会话 | session:{userId} |
登录态、购物车 | ★★★☆☆ |
| 配置/字典 | config:global |
全局开关、黑白名单 | ★★★☆☆ |
| 排行榜 | leaderboard:day |
游戏排名、销售排行 | ★★★☆☆ |
2.4 热点Key的检测方法
在实际生产环境中，可以通过以下方法快速定位热点Key：
- redis-cli --hotkeys 命令：Redis 4.0+ 内置热点Key扫描功能，基于LFU算法统计访问频率。
- MONITOR 命令采样：在低峰期执行
redis-cli monitor | head -n 10000，分析高频Key。 - 客户端统计：在应用层记录每个Key的访问次数，上报到监控系统。
- 代理层监控：使用Twemproxy、Codis或Redis Cluster的代理层统计Key访问分布。
注意事项：
MONITOR 命令会降低Redis性能约50%，严禁在生产高峰期使用。建议使用 --hotkeys 或客户端埋点方式。
2.5 热点Key的危害
热点Key如果不及时处理，会引发连锁反应：
- 单节点过载：CPU打满、内存带宽耗尽，导致该节点上的所有Key响应变慢。
- 集群雪崩：热点节点成为瓶颈，整体吞吐量下降，客户端超时重试加剧负载。
- 数据不一致：高并发下缓存更新和淘汰策略失效，可能导致脏数据。
- 业务受损：报表导出超时、页面加载失败、订单提交失败等直接经济损失。