如何解决多级缓存体系中Redis与本地缓存的同步击穿_基于MQ的刷新机制

多级缓存下Redis互斥锁无法防击穿，因本地缓存进程独占、过期不同步；必须用MQ统一协调回源，通过唯一key事件、Redis防重锁、幂等消费及可靠失效广播实现全局唯一重建。

多级缓存（Redis + 本地缓存）下，单纯靠 Redis 的互斥锁无法防止击穿——本地缓存没锁、不共享、过期时间不同步，会导致多个实例同时回源。 必须用外部协调机制把「谁来重建」这件事统一收口，MQ 是目前最稳妥的解法之一。

为什么本地缓存会让 Redis 互斥锁失效

本地缓存（如 Caffeine、Guava Cache）是进程内独占的。即使你在 Redis 层用 SETNX 加了锁，10 台服务实例各自有独立的本地缓存，它们都可能在同一毫秒发现本地缓存为空、同时查 Redis、同时发现 Redis 也为空，然后全部触发回源逻辑。

常见错误现象包括：

• 数据库 QPS 突增数倍，远超单台机器能承载的回源压力
• 日志里看到多个实例几乎同时打印「开始加载 user:123」
• 本地缓存设置了 5 分钟过期，Redis 设置了 10 分钟，但本地先过期 → 触发无效回源

根本原因不是锁没加，而是「锁的粒度没覆盖本地缓存这一层」。

用 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 防重 —— 避免网络重试导致重复发事件
• 消费者成功重建后，除了 SET Redis，还要发一条 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 消费端。