Redis怎样实现本地缓存的高效失效通知

Redis本地缓存失效通知不能依赖pub/sub，因其“发即忘”机制导致离线丢失；key过期事件有延迟、不覆盖主动删除；推荐用Redis List或Stream实现可重试的指令通道，并配合时间戳幂等控制。Redis 本地缓存失效通知为什么不能靠 pub/sub 直接推因为 PUB/SUB 是「发即忘」机制：消息不落地、无重试、订阅者离线就丢。本地缓存（比如进程内 Map 或 caffeine）如果靠它做失效通知，服务重启、网络抖动、消费延迟都会导致脏数据——这不是“偶尔不准”，而是“必然漏通知”。真实场景中，pub/sub 常用于广播「非关键」事件（如日志打点），不适合强一致性要求的缓存失效哪怕加了 redisson 的 RemoteCache 封装，底层仍是 PUB/SUB，没解决离线丢失问题如果你的本地缓存更新频率高、业务对 stale 数据敏感（比如库存、价格），这条路基本走不通用 Redis key 过期事件 + 订阅 __keyevent@0__:expired 可行吗可行，但有硬伤：Redis 默认不开启 key 过期监听，且事件只在 key 真正过期时触发——而本地缓存往往需要「主动失效」（比如手动 DEL 或 SET 覆盖），这时 expired 事件根本不会发。必须先配置 notify-keyspace-events Ex（注意不是 AEx，A 会额外发 del、set 等操作事件，噪音极大）即使开了，EXPIRE 后又 PEXPIRE 延长，事件可能被覆盖或延迟；集群模式下事件只发到所在 slot 的节点，客户端得连对节点才能收到更麻烦的是：事件到达有延迟（毫秒级），多个服务实例同时收到后，仍需自己做幂等判断，否则重复清本地缓存可能引发瞬时穿透真正靠谱的做法：用 Redis 作为「协调器」，本地缓存只响应明确指令核心思路是把「失效」变成「可查、可确认、可重试」的操作：不依赖事件推送，改由本地缓存定期轮询或监听一个中心化指令通道（比如用 LPUSH/BRPOP 模拟轻量队列）。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。