不能直接用 Redis Pub/Sub 做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK 或持久化机制；必须结合 Redis Stream 落地事件+数据库状态校验实现最终一致。
为什么不能直接用 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 <id>，否则该消息会持续出现在后续XREADGROUP中
注意：Stream 不支持通配符匹配 key，所以失效事件得带明确 key 字段，由业务代码解析后清理本地缓存（比如 Guava Cache 的 invalidate(key) 或 Caffeine 的 invalidate(key)）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
本地缓存清理前必须校验数据新鲜度
光清本地缓存还不够——如果此时数据库还没完成写入（例如主从延迟、事务未提交），立刻重建缓存就会把旧值又刷回去。
- 推荐在清理本地缓存后，**延迟 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 时机没对齐数据库状态。这个点一旦忽略，再多层消息通道也白搭。
