多级缓存下redis互斥锁无法防击穿，因本地缓存进程独占、过期不同步；必须用mq统一协调回源，通过唯一key事件、redis防重锁、幂等消费及可靠失效广播实现全局唯一重建。
多级缓存（Redis + 本地缓存）下，单纯靠 Redis 的互斥锁无法防止击穿——本地缓存没锁、不共享、过期时间不同步，会导致多个实例同时回源。 必须用外部协调机制把「谁来重建」这件事统一收口，MQ 是目前最稳妥的解法之一。
为什么本地缓存会让 Redis 互斥锁失效
本地缓存（如 Caffeine、Guava Cache）是进程内独占的。即使你在 Redis 层用 SETNX 加了锁，10 台服务实例各自有独立的本地缓存，它们都可能在同一毫秒发现本地缓存为空、同时查 Redis、同时发现 Redis 也为空，然后全部触发回源逻辑。
常见错误现象包括：
- 数据库 QPS 突增数倍，远超单台机器能承载的回源压力
- 日志里看到多个实例几乎同时打印「开始加载 user:123」
- 本地缓存设置了 5 分钟过期，Redis 设置了 10 分钟，但本地先过期 → 触发无效回源
根本原因不是锁没加，而是「锁的粒度没覆盖本地缓存这一层」。
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
用 MQ 实现「全局唯一回源」的关键设计点
核心思路：所有实例在发现两级缓存都缺失时，不直接查 DB，而是发一条 CacheRefreshEvent 到 MQ（如 Kafka/RocketMQ），由一个专属消费者负责执行重建，并写回 Redis 和广播清空本地缓存。
实操建议：
- 事件必须带唯一业务 key（如
"user:123"），消费者按 key 做并发控制（Kafka 单 partition 内有序，或 RocketMQ 按 key hash 到固定 queue） - 生产者发消息前，先尝试用 Redis 的
SET key_refresh_lock:user:123 "1" NX PX 30000防重 —— 避免网络重试导致重复发事件 - 消费者成功重建后，除了
SETRedis，还要发一条CacheInvalidateEvent到 topic（如cache-invalidate），各实例监听并调用localCache.invalidate("user:123") - 本地缓存建议启用
refreshAfterWrite（Caffeine）而非expireAfterWrite，让旧值继续服务，后台异步刷新，降低击穿感知
MQ 方案下容易被忽略的三个坑
这不是加个 producer/consumer 就完事的事，踩错一步就退化成裸奔状态：
-
CacheRefreshEvent消息没做幂等消费：消费者重启或重平衡后重复处理，导致 DB 被反复查询。必须用 Redis 记录已处理 event ID 或业务 key 的最后刷新时间戳，消费前校验 - 本地缓存 invalidate 广播丢失：MQ 消费失败未重试、topic 无备份、消费者 group offset 提交过快。建议用至少 once 语义，且本地缓存失效操作加 fallback 日志告警
- Redis 缓存写入和 MQ 发送不在同一事务：DB 查询成功但 Redis
SET失败，或 MQ 发送失败但本地缓存已清空。应将 Redis 写入作为消息生产的前置条件，失败则不发消息
真正难的不是发消息，而是让「本地缓存失效」这个动作，在分布式环境下做到可靠、及时、可追溯。MQ 只是管道，关键在事件 payload 设计、消费者幂等性、以及本地缓存与消息生命周期的对齐。否则，你只是把击穿从数据库搬到了 MQ 消费端。
