Redis发布订阅实现缓存清理方案

Redis的Pub/Sub机制虽能实现低延迟的缓存失效通知，但因其缺乏消息持久化、ACK确认和重试能力，无法单独保障缓存一致性——订阅者离线即丢消息，极易导致本地缓存脏数据；真正可靠的方案是“数据库先行写入 + Redis Stream 落地事件 + 消费者组ACK保障 + 数据库状态校验”，辅以Pub/Sub仅作轻量级实时提示；关键在于清理本地缓存后必须延迟重载或通过SELECT FOR UPDATE/版本号比对确保读到最新数据，否则高并发下极易引发缓存雪崩——一致性不是靠消息通道堆砌，而是靠事件可靠投递与数据状态严格对齐。

为什么不能直接用 Redis Pub/Sub 做缓存一致性保障

Redis 的 PUBSUB 本身不保证消息可达：订阅者离线时消息直接丢失，没有重试、ACK 或持久化机制。这意味着如果某个服务实例在缓存更新时恰好断连，它的本地缓存就再也收不到失效通知，变成脏数据。

所以真实场景中，PUBSUB 只能当“辅助通道”，真正扛一致性的是“事件落地 + 轮询/监听补偿”组合。核心思路是：先写数据库，再发事件（写入可靠队列或 Redis Stream），最后用 PUBSUB 做低延迟广播，仅服务于在线实例的快速响应。

用 Redis Stream 替代纯 Pub/Sub 存储失效事件

Redis Stream 提供了持久化、消费者组、ACK 确认和重播能力，适合承载关键的缓存失效指令。相比 PUBLISH/PSUBSCRIBE，它让“谁没收到”变得可查可控。

• XADD cache-invalidate * key user:1001 op DELETE —— 每次缓存变更都追加一条结构化事件
• 各服务启动时创建专属消费者组：XGROUP CREATE cache-invalidate mygroup $ MKSTREAM
• 运行时用 XREADGROUP GROUP mygroup consumer-1 COUNT 10 BLOCK 5000 STREAMS cache-invalidate > 拉取未处理事件
• 成功处理后必须调用 XACK cache-invalidate mygroup ，否则该消息会持续出现在后续 XREADGROUP 中

注意：Stream 不支持通配符匹配 key，所以失效事件得带明确 key 字段，由业务代码解析后清理本地缓存（比如 Guava Cache 的 invalidate(key) 或 Caffeine 的 invalidate(key)）。

本地缓存清理前必须校验数据新鲜度

光清本地缓存还不够——如果此时数据库还没完成写入（例如主从延迟、事务未提交），立刻重建缓存就会把旧值又刷回去。

• 推荐在清理本地缓存后，**延迟 100–500ms 再尝试 reload**，给数据库同步留出窗口
• 更稳妥的做法是：清理本地缓存 → 向 DB 发起一次 SELECT ... FOR UPDATE 或带版本号的查询 → 确认最新值后再写入本地缓存
• 若使用乐观锁（如 version 字段），可在失效事件里附带预期版本：XADD ... version 123，reload 时比对 DB 当前 version 是否 ≥ 该值

跳过校验直接 reload 是多数缓存雪崩的源头之一，尤其在高并发更新同 key 场景下。

Pub/Sub 仅用于轻量级实时提示，不承载关键逻辑

可以保留 PUBLISH cache-invalidate-notify "{"key":"user:1001","op":"DELETE"}" 作为补充信号，但只用于触发“预热准备”或“标记待刷新”，不替代 Stream 的主流程。

• 订阅端收到 cache-invalidate-notify 后，只设一个 refreshPending.getAndSet(true) 标志位
• 真正 reload 动作仍由后台定时任务或下次请求时按需触发，并再次走 Stream + DB 校验路径
• 避免在 SUBSCRIBE 回调里做 DB 查询或复杂计算，防止阻塞事件循环（尤其是 Node.js 或单线程 Redis 客户端）

很多人卡在“为什么本地缓存清了但还是读到旧值”，其实问题不在 Redis，而在 reload 时机没对齐数据库状态。这个点一旦忽略，再多层消息通道也白搭。

理论要掌握，实操不能落！以上关于《Redis发布订阅实现缓存清理方案》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！