Redis集群不支持MONITOR命令，因其为单实例设计且无法跨节点监听；推荐使用redis-cli --hotkeys（需LFU策略）或代理层/tcpdump/SDK埋点方案，并注意OBJECT FREQ的衰减误差与业务语义过滤。
Redis集群中不能直接用 MONITOR 命令发现热点Key——它不支持集群模式，执行会报错 ERR This Redis command is not supported in cluster mode。
为什么 MONITOR 在 Redis 集群里根本跑不起来
Redis 集群将 Key 拆分到多个节点（shard），而 MONITOR 是单实例命令，只能监听当前连接的节点。你连上任意一个节点执行 MONITOR，只能看到发往该节点的请求；但热点Key可能落在其他节点上，且客户端通常通过哈希槽自动路由，你甚至不知道它在哪台机器上。
- 集群环境下执行
MONITOR会立即返回错误，不是“没效果”，而是被明确拒绝 - 即使你在所有节点上分别启动
MONITOR，也无法关联同一 Key 的跨节点访问（比如重定向、MOVED 响应等场景） - 输出日志无时间戳、无客户端标识、无命令耗时，纯文本解析成本高，不适合自动化分析
redis-cli --hotkeys 是更靠谱的起点
Redis 4.0.3+ 提供的 --hotkeys 是集群友好的内置方案：它基于采样统计（非全量监听），对性能影响极小，且能自动遍历所有主节点。
- 运行方式：
redis-cli -c -h {host} -p {port} --hotkeys（-c表示集群模式） - 原理是周期性调用
SCAN+OBJECT FREQ（或LATENCY LATEST辅助判断），只采样活跃 Key - 输出格式为
key_name freq，按访问频次倒序，前 10 名即热点候选 - 注意：它依赖
maxmemory-policy配置为allkeys-lfu或volatile-lfu才能准确反映访问热度
真要抓实时流量，得换 TCP 层或代理层方案
当 --hotkeys 不够细（比如需要毫秒级突增识别、带客户端 IP/命令类型维度），就得绕过 Redis 协议层本身。
- 在 Redis 前加一层代理（如 Twemproxy、Codis、或自研 Proxy），在转发逻辑里埋点统计 Key 访问频次，再聚合上报
- 用
tcpdump抓包 +redis-faina解析：抓取 Redis 端口（默认 6379）的 TCP 流量，还原 RESP 协议，过滤出高频 Key —— 这能跨节点统一分析，但需确保抓包覆盖所有入口（比如有 TLS 代理则需解密） - 客户端 SDK 埋点：在业务代码的 Redis 调用处（如
jedis.get(key)）加计数器，异步上报，适合已接入监控体系（如 Prometheus）的团队
别忽略 OBJECT FREQ 的精度陷阱
OBJECT FREQ 返回的是 LFU 计数器的近似值，不是精确访问次数，受衰减因子影响大。
- 默认每分钟衰减一次，如果 Key 在 1 秒内被访问 1000 次，
OBJECT FREQ可能只返回 200～300 - 衰减参数由
lfu-log-factor和lfu-decay-time控制，生产环境建议调低lfu-decay-time（如设为 1）来提升敏感度 - 单独查一个 Key 的频次没意义，必须结合时间窗口做同比/环比（例如“过去 60 秒 vs 前 60 秒”）才能识别突增
真正难的不是“怎么看到热点”，而是“看到之后怎么确认它是真热点而非误报”。比如 _sentinel:hello 频次高只是哨兵心跳，PING 多可能是连接池保活——这些都得结合命令类型、Key 前缀、业务语义一起过滤，不能光看数字。
