3. 热点Key的发现手段一：Redis内置命令（hotkeys、monitor、slowlog）的局限与实战
在生产环境中定位热点Key，最直接的想法是使用Redis自带的命令。然而，这些命令在设计之初并非为“持续热点发现”而生，直接在生产环境使用存在诸多风险与局限。本节将逐一剖析 hotkeys、MONITOR、SLOWLOG 的原理、适用场景及实战中的“坑”。
3.1 三大内置命令的核心机制与输出示例
| 命令 | 触发方式 | 输出内容 | 性能影响 |
|---|---|---|---|
redis-cli --hotkeys |
扫描整个Keyspace，结合 OBJECT freq 统计访问频率 |
按访问频次排序的热点Key列表（需开启 maxmemory-policy 且为 allkeys-lfu 或 volatile-lfu） |
高：全库扫描，阻塞单线程，大数据量下可能秒级卡顿 |
MONITOR |
实时打印所有Redis命令 | 逐行输出客户端IP、时间戳、命令及参数 | 极高：单线程处理，输出量巨大，瞬间拉高CPU，生产慎用 |
SLOWLOG |
记录执行时间超过 slowlog-log-slower-than 的慢查询 |
命令耗时、时间戳、命令详情 | 低：异步记录，不阻塞主流程 |
实战要点： 在6.0+版本中，
--hotkeys 依赖LFU淘汰策略。若实例未配置 allkeys-lfu 或 volatile-lfu，该命令将返回空结果或报错。务必在测试环境验证策略配置。
3.2 局限一：hotkeys —— 全库扫描的“性能炸弹”
redis-cli --hotkeys 的本质是遍历所有Key并调用 OBJECT freq 获取访问频次。在Key数量超过千万级的实例上，该操作会长时间占用主线程CPU，导致正常请求延迟飙升甚至超时。
# 执行hotkeys扫描（生产环境慎用）
$ redis-cli --hotkeys
# 输出示例（部分）
# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Key: user:login:10086 (type: string, freq: 150)
[00.01%] Key: product:hot:9527 (type: string, freq: 120)
...
-------- summary -------
Sampled 5000000 keys in the keyspace!
hot key found count: 2
避坑指南： 不要在业务高峰期执行
--hotkeys。若必须使用，建议配合 -i 参数增加休眠间隔（如 -i 0.5），降低扫描速度，但即便如此仍存在风险。更安全的做法是使用 SCAN 命令配合 OBJECT freq 自行实现采样逻辑。
3.3 局限二：MONITOR —— 实时流量的“放大镜”与“CPU杀手”
MONITOR 命令会实时输出所有命令，在QPS达到数万的实例上，其输出量可达每秒数MB甚至数十MB。这不仅消耗大量CPU资源用于格式化输出，还会因输出缓冲区膨胀导致客户端内存溢出。
# 启动MONITOR（生产环境绝对禁止长时间开启）
$ redis-cli MONITOR
OK
1625123456.789012 [0 10.0.0.1:54321] "GET" "user:profile:10086"
1625123456.789123 [0 10.0.0.2:54322] "SET" "session:abc123" "data"
1625123456.789234 [0 10.0.0.1:54321] "GET" "user:profile:10086"
...
替代方案： 若仅需统计Key访问频率，可使用
redis-cli --stat 查看实时吞吐量，或通过 INFO commandstats 获取命令级别的调用次数分布，避免逐条抓取。
3.4 局限三：SLOWLOG —— 只能发现“慢Key”，无法发现“热Key”
SLOWLOG 记录的是执行时间超过阈值的命令。热点Key通常访问频率极高，但单次操作可能极快（如 GET 一个几字节的字符串），不会触发慢查询。因此，SLOWLOG 无法直接发现高频访问的热点Key，只能辅助排查因热点Key导致的间接慢查询（如大Key的频繁读写）。
# 查看最近10条慢查询
$ redis-cli SLOWLOG GET 10
1) 1) (integer) 14
2) (integer) 1625123456
3) (integer) 12000
4) 1) "HGETALL"
2) "user:big_hash:10086"
5) "127.0.0.1:6379"
6) ""
结论： SLOWLOG 适合定位“大Key”或“复杂命令”导致的延迟，但无法替代热点Key发现。热点Key的发现需要基于访问频率，而非单次执行耗时。
3.5 三种命令的适用场景对比
| 场景 | 推荐命令 | 理由 |
|---|---|---|
| 测试环境快速验证热点Key是否存在 | --hotkeys |
数据量小，扫描速度快，无业务风险 |
| 定位大Key或慢查询 | SLOWLOG + --bigkeys |
针对性强，性能影响可控 |
| 生产环境实时流量分析 | 禁止使用 MONITOR |
应使用客户端侧统计或Redis 7.0+的 CLIENT LIST 增强功能 |
| 生产环境热点Key发现 | 第三方工具或自定义采样 | 内置命令均存在性能或功能缺陷，需借助外部方案 |
3.6 实战总结：内置命令的“能”与“不能”
通过上述分析，可以清晰看到Redis内置命令在热点Key发现上的能力边界：
- 能做的： 在低负载、小数据量的测试环境快速定位热点；作为辅助手段验证其他工具的结果。
- 不能做的： 在生产环境持续、低开销地监控热点Key；无法区分“热Key”与“大Key”对系统的影响。
下图总结了三种内置命令在热点Key发现流程中的位置与局限：