热点Key需早识别、快拦截、稳兜底：首选redis-cli --hotkeys（需LFU策略），辅以Proxy埋点或客户端AOP统计；本地缓存须设短TTL、主动预热、分级过期，并配合Key分片与双层限流。
发现热点 Key 并加本地缓存防护，核心是“早识别、快拦截、稳兜底”。不能等它打垮 Redis 才反应，得在流量涌来前或刚起势时就介入。
怎么快速发现 HotKey
生产环境不靠猜，要靠可观测手段组合使用：
-
Redis 自带 --hotkeys（推荐首选）：4.0+ 版本支持，需提前配置 maxmemory-policy allkeys-lfu 或 volatile-lfu。执行
redis-cli --hotkeys可直接输出访问频次最高的 Key 列表，比如：[HotKey] seckill:goods:1001(accesscount:421305)。
注意：不是实时流式统计，而是采样扫描，适合日常巡检和大促前摸底。 - Proxy 层埋点（业务无感）：如果用了 Twemproxy、Codis 或自研 Redis Proxy，在请求分发环节统计 Key 访问频次并上报 Kafka/Pulsar，再用 Flink 或 Spark 实时聚合，5 秒级发现突增 Key。这是大厂主流做法，对应用零侵入。
-
客户端 AOP 拦截（精准但有成本）：在 Jedis/Lettuce 封装层统一拦截
get/hget等读命令，用ConcurrentHashMap + LongAdder统计 Key 计数，定时异步上报。适合中小团队快速上线，但要注意内存控制（如只保留 top 1000 Key）和 GC 压力。 -
慎用 MONITOR：仅限临时排查，
redis-cli monitor | head -n 1000会拖慢 Redis 吞吐 50% 以上，严禁长期开启。
本地缓存怎么设才真正防住穿透
本地缓存不是简单加个 GuavaCache 就完事，关键在“命中率”和“一致性”平衡：
- 自动加载 + 主动刷新：发现 HotKey 后，不等第一次请求触发加载，而是由监控系统主动调用服务接口，把 Key 值预热进本地缓存（如 Caffeine），并设置 refreshAfterWrite(30s)，避免过期瞬间全量回源。
- 分级过期策略：对秒杀类 Key，本地缓存 TTL 设为 1~2 秒（极短），配合后台异步刷新；对新闻类 Key，可设 10~30 秒，降低刷新频率。
- 多实例缓存不共享，但需协同失效：100 台应用节点各自缓存同一 Key，不会互相干扰，但如果 DB 更新了该 Key，需通过消息通知所有节点清空本地副本，否则出现脏数据。可用 Redis Pub/Sub 或 RocketMQ 广播 invalidate 指令。
- 拒绝 fallback 到远程缓存：本地缓存未命中时，不要立刻查 Redis——这会让本地缓存形同虚设。应直接返回默认值、降级结果，或走限流逻辑，确保本地缓存真正承担主流量。
配套必须做的两件事
单做本地缓存容易翻车，必须搭配：
-
对 HotKey 做哈希分片：比如原 Key 是
item:1001，拆成item:1001:shard001~item:1001:shard010，请求时按用户 ID 或随机哈希选择子 Key。写操作需合并，读操作天然分散，Redis 层压力直降 90%。 - 本地缓存 + Redis 双层限流：在本地缓存入口加令牌桶（如 Sentinel 或 Resilience4j），单机 QPS 超 500 就熔断；Redis 层再用 Lua 脚本做集群级限流，防止某台机器缓存失效后雪崩式打穿。
