Redis 不支持自动发现热点 Key 与 Sentinel 联动；Sentinel 仅负责高可用，无 key 级统计能力，热点 Key 需通过客户端埋点或 --hotkeys 直连实例采集。
Redis 本身不提供“自动发现热点 Key + Sentinel 联动”的开箱即用能力。Sentinel 只负责监控主从状态、故障转移和配置分发，它不采集或暴露 key 级访问频次数据。所谓“结合 Sentinel 统计机制拦截”，是常见误解——Sentinel 没有统计机制，更不会拦截命令。
redis-cli --hotkeys 能否配合 Sentinel 使用？
redis-cli --hotkeys 是 Redis 4.0+ 提供的 LFU（Least Frequently Used）采样命令，依赖节点开启 maxmemory-policy 为 allkeys-lfu 或 volatile-lfu 才能生效。它只作用于单个 Redis 实例，与 Sentinel 完全无关：
- Sentinel 不转发该命令，也不参与其执行
- 你必须直连具体 Redis 节点（比如当前 Master 地址），不能连 Sentinel 地址去跑
--hotkeys - 如果 Master 切换，需重新获取新 Master 地址再执行，无法靠 Sentinel 自动路由
如何在 Sentinel 架构下实际捕获热点 Key？
真正可行的方式，是在客户端或代理层做主动采集，再结合 Sentinel 提供的当前 Master 地址做定向分析：
- 在应用侧用 AOP 或 Redis 客户端拦截器（如 Lettuce 的
CommandListener）记录高频GET/HGET的 key 名，聚合后上报 Prometheus 或写入本地日志 - 通过 Sentinel 的
SENTINEL get-master-addr-by-name命令动态获取当前 Master 地址：redis-cli -h sentinel-host -p 26379 SENTINEL get-master-addr-by-name mymaster
- 拿到 Master 地址后，再用
redis-cli -h $master_ip -p $master_port --hotkeys或monitor（仅调试）做临时验证 - 切勿在生产环境长期跑
monitor：它会使 Redis 吞吐下降 50%+，且 Sentinel 无法缓解该副作用
为什么不能依赖 Sentinel 做热点发现？
Sentinel 的设计目标是高可用，不是可观测性。它的监控粒度停留在实例级别（如 is-master-down-by-addr、down-after-milliseconds），不包含以下关键能力：
- 无 key 访问计数器（不像 Redis Server 内置的 LFU 或自定义 INFO 字段）
- 无命令采样或慢日志聚合能力（
slowlog需手动查每个节点） - 不提供 Pub/Sub 通道广播“某个 key 被访问了 N 次”这类事件
- 即使你给 Sentinel 加插件，它也无权限读取 Redis 内部 key 的访问频率内存结构
真正落地时，热点 Key 发现永远要绕回两个支点：要么在 Redis 实例上启用 LFU 并定期拉取（--hotkeys），要么在客户端埋点统计。Sentinel 只负责告诉你“现在该打谁”，但绝不会告诉你“哪个 key 正在被打爆”。
