redis-cli --hotkeys 是最轻量起点，需启用 lfu 策略并预热；代理层聚合统计为生产首选，兼顾实时性与低侵入性；抓包分析精准但高开销，仅限紧急定位；客户端埋点适合灰度验证。
要快速定位 Redis 热点 Key，关键不是“扫全量”，而是分层聚焦——从服务入口到数据节点，逐级缩小可疑范围。实时性、侵入性、准确性三者需权衡，没有银弹，但有适配路径。
用 redis-cli --hotkeys 快速摸底
Redis 4.0+ 内置的 redis-cli --hotkeys 是最轻量的起点。它基于采样扫描（SCAN + OBJECT FREQ），不改代码、不加依赖，适合日常巡检或故障初判。
- 执行后会输出类似 [62.3%] hot key 'order:20260708:summary' found: 89200 hits 的结果，百分比代表该 key 占当前采样窗口总请求的比例
- 注意：它不反映绝对 QPS，只反映相对热度；扫描耗时随 key 总数线性增长，千万级 keyspace 可能需数分钟
- 建议搭配 INFO stats 中的 instantaneous_ops_per_sec 对比，确认是否真处于高负载段
在代理层聚合统计（推荐生产首选）
如果所有 Redis 请求都经过自研或可控 Proxy（如 Codis、Twemproxy、或内部 Samaritan 类系统），在代理层埋点统计是最平衡的方案：零客户端改造、多语言兼容、数据粒度细（可带 client IP、命令类型、耗时）。
- 每秒聚合每个 key 的访问次数，滑动窗口（如最近 10 秒）内超过阈值（例如 5000 次/秒）即告警
- 支持按 读/写分离统计，区分是 GET 热还是 SET 热，这对后续方案选型（如本地缓存 or 分片）很关键
- 需注意代理自身 CPU 和内存开销，建议采样率可调（如 1% 流量全量统计，其余仅计数不记详情）
抓包分析：精准但需谨慎使用
当怀疑某节点已出现流量倾斜（如监控显示某分片网卡打满、CPU 持续 95%+），可在该节点用 tcpdump 抓取 Redis TCP 流量，再离线解析还原 key 访问分布。
- 命令示例：tcpdump -i any -s 0 -w redis.pcap port 6379，之后用 Python 或 redis-faina 解析
- 优点是真实、无遗漏，能识别出未走代理或绕过 SDK 的异常调用
- 缺点明显：抓包本身加重负载，不建议长期开启；且无法区分重试请求与真实业务请求
客户端侧轻量埋点（适合灰度验证）
在关键业务 SDK 中增加低开销计数器（如 AtomicLong），对高频访问的 key 做本地累加，定时上报（如每 5 秒 flush 一次）。不记录完整请求，只报 key 名和次数。
- 适合已有统一 SDK 架构的团队，能快速上线验证某个模块是否产生热 key
- 务必设置采样开关，避免日志爆炸；同时 key 名要做脱敏或哈希（防敏感信息泄露）
- 注意时钟漂移和上报失败重试机制，否则统计数据可能失真
