Redis集群不支持热点Key自动发现，必须依赖Proxy或客户端埋点实现实时识别；redis-cli --hotkeys仅适合低峰期离线扫描，存在阻塞主线程、频次估算误差大、无时间窗口统计等缺陷，无法用于生产环境实时告警。

Redis集群本身不提供热点Key自动发现能力，必须依赖外部手段采集+规则判断，否则集群只会默默把所有请求打到同一个分片上，直到节点被打挂。

redis-cli --hotkeys 只能离线扫描，不能用于生产环境实时告警

此命令在Redis 4.0.3+版本中可用，但它会全量遍历键空间，执行时会阻塞主线程。在QPS较高的集群上运行一次，可能会导致服务器卡住几秒甚至更久。因此，它仅适用于在低峰期进行人工排查，例如在凌晨执行 redis-cli -h xxx --hotkeys 命令。然而，它无法作为自动监控链路的一部分。

• 输出结果只包含访问频次估算（基于 LRU 淘汰计数器），不是真实 QPS，误差大
• 无法区分是“突发流量”还是“持续热点”，更没法设定动态阈值
• 没有时间窗口概念，不能做滑动窗口统计（比如最近 60 秒内每秒访问超 5000 次才标为热点）

真正可用的自动发现必须在 Proxy 或客户端层埋点

要实现实时、低开销、可扩展的热点识别，只能把统计逻辑前置。常见可靠路径有两条：

• Proxy 层采集：如使用 Codis 或自研 Proxy，在转发 GET/HGET 请求前记录 key 和时间戳，用 Redis Sorted Set + Lua 做滑动窗口计数（例如用 ZREMRANGEBYSCORE 清理过期数据，ZCOUNT 判定是否超阈值）
• 客户端 SDK 埋点：在 Jedis/Lettuce 封装层拦截命令，对指定 pattern 的 key（如 product:*|activity:*|news:* ）做本地原子计数，每 10 秒聚合上报到 Kafka/Prometheus；避免每次请求都打远程服务

注意：不要在业务代码里直接调用 AtomicLong.incrementAndGet() 统计——高并发下会成为性能瓶颈；要用无锁 RingBuffer 或批处理缓冲区。

发现后必须立刻做 Key 打散，否则自动发现毫无意义

检测到 hotkey:123 是热点，只是第一步。若不做处理，下个请求照样打到同一 slot、同一节点。最轻量且通用的做法是客户端侧加随机后缀分片：

String baseKey = "hotkey:123";
String shardKey = baseKey + ":" + ThreadLocalRandom.current().nextInt(16); // 16 个分片
String value = redisClient.get(shardKey);

• 分片数建议设为 2 的幂（如 8/16/32），避免取模运算损耗
• 后缀不能用时间戳或递增 ID，否则失去打散效果；必须是真随机或一致性哈希
• 如果业务要求强一致性（如库存扣减），需配合分布式锁或串行化更新，不能简单拆分

本地缓存不是万能解药，容易引发脏读和内存失控

用 Caffeine 缓存 hotkey:123 看似简单，但有两个硬伤：

• 失效策略难对齐：Redis 过期是被动删除，本地缓存是主动定时清理，两者 TTL 微小差异就会导致脏数据
• 内存水平不可控：如果误判 1000 个 key 都是热点，每个缓存 1MB，瞬间吃掉 1GB 堆内存

更为可靠的方式是，仅针对明确在白名单内的key（比如 config:activity:202607）开启本地缓存，并设置 maximumSize(100) 以及 expireAfterWrite(3, TimeUnit.SECONDS) 。同时，监听Redis的 __keyevent@0__:expired Pub/Sub事件，以此来进行被动刷新。

真正的难点不在“怎么发现”，而在于“发现后如何让整个调用链自动适配新分片逻辑”——这需要客户端、Proxy、监控系统三端协同，且任何一环缺失都会让自动机制失效。很多团队卡在落地阶段，不是因为技术不行，而是没想清楚边界责任归属。