Redis HotKey 热点key怎么发现并做本地缓存防护-java教程-PHP中文网

热点Key需早识别、快拦截、稳兜底：首选redis-cli --hotkeys（需LFU策略），辅以Proxy埋点或客户端AOP统计；本地缓存须设短TTL、主动预热、分级过期，并配合Key分片与双层限流。

redis hotkey 热点key怎么发现并做本地缓存防护

发现热点 Key 并加本地缓存防护，核心是“早识别、快拦截、稳兜底”。不能等它打垮 Redis 才反应，得在流量涌来前或刚起势时就介入。

生产环境不靠猜，要靠可观测手段组合使用：

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 就完事，关键在“命中率”和“一致性”平衡：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

自动加载 + 主动刷新：发现 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 脚本做集群级限流，防止某台机器缓存失效后雪崩式打穿。