多级缓存同步击穿：基于MQ的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 消费端。