redis-cli --hotkeys在生产中基本不可用，因其依赖LFU策略（需显式配置）、统计衰减导致漏报、且仅返回key名无QPS/命令等上下文。
生产环境不能靠 redis-cli --hotkeys 实时抓取热 key——它依赖 LFU 计数器，需提前开启 maxmemory-policy allkeys-lfu 或 volatile-lfu，且统计窗口不可控、延迟高、无法区分瞬时脉冲与持续热点。
为什么 redis-cli --hotkeys 在生产中基本不可用
该命令本质是读取 Redis 内置的 LFU 近似计数器，但存在三个硬伤：
- LFU 统计本身有衰减机制（默认 10 分钟衰减一次），突发秒杀流量可能刚被计入就衰减，漏报率高
- 必须在配置中显式启用 LFU 策略，而多数线上集群使用
allkeys-lru或noeviction，直接执行会返回空或报错ERR unknown command `--hotkeys` - 它只返回 top-N 的 key 名，不带 QPS、响应耗时、客户端 IP、命令类型等上下文，无法判断是真实业务热点还是爬虫刷量
用 Redis Proxy 日志做无侵入热 key 探测
真正可落地的方案是让流量经过一个可控中间层，比如 Twemproxy、Codis Proxy 或自研网关，在请求出口侧埋点采集。关键不是“Redis 能不能统计”，而是“谁在调用、怎么调用、调用多快”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每条日志至少包含：
timestamp、client_ip、command（如HGET）、key、duration_ms、status - 用 Flink 或 Logstash 按
key+1s窗口聚合 QPS，阈值设为单节点承载能力的 30%（例如单节点实测极限 20 万 QPS，则告警线设为 6 万） - 对命中阈值的 key，额外标记其
command类型：若高频GET且 value 小 → 适合本地缓存；若高频HGETALL→ 很可能已是 BigKey，需联动治理
热 key 发现后如何零抖动分流
发现热 key 后立刻改代码加缓存？来不及。要的是秒级生效、不发版、不影响存量逻辑的分流能力。
- 在接入层（如 Nginx/OpenResty）或 SDK 层注入透明代理逻辑：当检测到请求 key 匹配热 key 规则库时，自动降级走本地 Caffeine 缓存，并异步刷新
- 本地缓存 TTL 必须设为极短（如
expireAfterWrite(2, TimeUnit.SECONDS)），避免 stale data；同时用refreshAfterWrite触发后台异步 reload，保证一致性 - 关键动作是广播失效：Redis 中该 key 更新时，通过 Pub/Sub 或 Kafka 向所有客户端推送
invalidate:sku:10086消息，各端收到后清除本地副本——注意不是删，是设为空并触发下一次 reload
容易被忽略的两个致命细节
一是热 key 的“冷启动放大效应”：刚被识别为热 key 时，本地缓存为空，所有请求穿透到 Redis，反而造成二次冲击。解决方案是在探测系统中标记“预热中”状态，对该 key 主动预加载一次到各客户端本地。
二是客户端缓存粒度陷阱：不要缓存整个 HASH 结构，而应按字段拆（如 sku:10086:price、sku:10086:stock），否则一个字段更新就得清空全部，失去局部性优势。
