能，但需先将 maxmemory-policy 设为 volatile-lfu 或 allkeys-lfu；否则命令报错或无输出，且 redis 版本须 ≥4.0。
redis-cli --hotkeys 能直接查到热点 Key 吗？
能，但有硬性前提：必须把 maxmemory-policy 设为 volatile-lfu 或 allkeys-lfu，否则命令执行会报错或返回空。LFU（Least Frequently Used）淘汰策略启用后，Redis 才会持续统计每个 key 的访问频次，redis-cli --hotkeys 才能基于这个计数器输出结果。
常见错误现象是执行后无输出，或者提示 ERR unknown command `--hotkeys` ——后者说明 Redis 版本低于 4.0；前者大概率是淘汰策略没配对。
- 检查当前策略：
redis-cli config get maxmemory-policy - 临时修改（需有权限）：
redis-cli config set maxmemory-policy allkeys-lfu - 注意：该配置重启失效，需写入
redis.conf并 reload 或重启
MONITOR 命令抓热点 Key 为什么只适合临时排查？
因为 redis-cli MONITOR 是全量命令嗅探，每条命令都会被复制并输出，Redis 主线程要额外做日志序列化和网络发送，实测吞吐量会下降 50% 以上。生产环境持续开着，等于主动给自己加压。
它真正适用的场景只有一个：你已经观察到某段时间内延迟突增、CPU 打满，且怀疑是瞬时热点（比如整点秒杀刚开），需要快速定位前 20 个高频 key。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 安全用法示例：
redis-cli MONITOR | grep -E "(GET|HGET|ZSCORE)" | awk '{print $NF}' | sort | uniq -c | sort -nr | head -20 - 务必加
timeout 30s或手动Ctrl+C中断，绝不能后台常驻 - 如果管道中漏掉
grep过滤，MONITOR输出的SET、EXPIRE等写命令会污染统计结果
为什么 --hotkeys 输出里带百分比，但不能直接当 QPS 看？
redis-cli --hotkeys 输出的 [45.45%] Hot key 'product:1001:info' found: 120000 hits 中的百分比，是「该 key 在本次采样窗口内的访问占比」，不是实时 QPS。LFU 计数器是累积值，不重置，也不按秒归一化。
这意味着：同一个 key 显示 80% 占比，可能是过去一小时被集中刷了 10 万次，也可能是最近 10 秒内来了 8 万次——你无法从这个数字判断是否正在击穿。
- 想估算真实 QPS，得配合
redis-cli info stats | grep instantaneous_ops_per_sec看当前实例总 QPS，再人工交叉比对时间窗口 - 更靠谱的做法是用
SLOWLOG GET 10查最近慢查询，看是否有大量同 key 的GET出现在同一毫秒级时间戳下 - 百分比高 ≠ 正在击穿；但百分比 +
instantaneous_ops_per_sec突增 +used_cpu_sys持续 > 90%，基本可确认
发现热点 Key 后，光改 Redis 配置没用，下一步必须做什么？
停掉 --hotkeys 或 MONITOR 后，立刻在应用层加本地缓存或分片逻辑。Redis 自身没有“自动分流”或“自动降级”机制，监控只是诊断手段，治理必须落在代码或架构上。
最容易被忽略的一点是：热点 Key 往往伴随缓存击穿风险，而 --hotkeys 只告诉你“谁被狂刷”，不告诉你“它有没有过期”。所以发现后第一件事，是查 ttl product:1001:info ——如果 TTL 小于 10 秒，必须同步加互斥锁或本地短时缓存，否则下一秒就可能雪崩。
- 不要等“下次再观察”，热点 Key 的生命周期可能只有几十秒
- 不要只依赖 Redis 层解决，JVM 本地缓存（如
Caffeine）的expireAfterWrite(1, TimeUnit.SECONDS)是最轻量的兜底 - 如果 key 是库存类（如
stock:1001），必须立刻切分，原始 key 已经不可信
