热 key 是什么
热 key 指单位时间内访问次数远超其他键的键，常见于榜单、秒杀库存、全局配置这类被全站集中读写的对象。它的问题不在数据量大小，而在流量集中在单个分片：Redis 处理命令是单线程的，某个键的 QPS 再高也只由一个节点一个线程扛，请求排队后延迟直接上扬，扩容分片对单个热点键没有帮助。
基本信息
| 适用平台 | Redis 4.0+；--hotkeys 要求淘汰策略为 LFU 系列 |
|---|---|
| 主要手段 | redis-cli --hotkeys、MONITOR 限时采样、代理或客户端埋点 |
| 判断口径 | 单键 QPS 占比过高，如 10 万 QPS 里有 3 万打同一个键 |
| 前提 | 读热点与写热点处置方式完全不同，先分清再动手 |
典型使用场景
- 大促前评审榜单、库存、配置类键的访问集中度，提前做读分摊
- 实例延迟抖动但 CPU、内存都不高：优先怀疑单键排队而非资源不足
- 集群扩容的容量评审：确认瓶颈是热点还是总量，避免扩容无效
- 客户端超时集中上报时，核对是否集中在同一个键或同一类键
- 某个节点网卡被打满而其他节点空闲，需要定位流量来源
排查手段
排查手段
# 前提：淘汰策略切到 LFU，--hotkeys 才可用
CONFIG SET maxmemory-policy allkeys-lfu
redis-cli --hotkeys # 按 LFU 计数输出访问频次榜
# 限时命令流采样，避免输出洪流
# timeout 5 redis-cli MONITOR | awk '{print $4}' | sort | uniq -c | sort -rn | head
redis-cli --bigkeys # 顺带确认是否存在大 key 放大单键成本
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|total_commands_processed'三种手段对比
| 手段 | 适用 | 代价 |
|---|---|---|
| --hotkeys | 扫描全键按 LFU 计数排序 | 需 LFU 策略；大实例扫描耗时 |
| MONITOR 采样 | 看到真实命令流，可核对调用方 | 高 QPS 下输出洪流，拖慢实例 |
| 代理或客户端埋点 | 长期统计单键 QPS 与来源 | 需改代码或依赖代理能力 |
热点通常来自业务设计本身（榜单、秒杀库存、全局配置键）：排查手段只负责定位，真正解决要在业务侧做读分摊（多副本、本地缓存）或写合并。
MONITOR 会把命令及其参数（可能含手机号、令牌等敏感值）打印到终端：生产只允许短时限时采样，输出不要落盘、不要贴进工单。