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 模拟轻量队列）。
- 写操作时，除了更新 Redis，再
LPUSH cache:invalidation [key]到一个 list；本地缓存服务用BRPOP cache:invalidation 0阻塞监听（单连接即可支撑多实例） - 为防消息丢失，list 可配合
EXPIRE cache:invalidation 3600自清理，但注意不要设太短，避免误删未消费消息 - 如果用
Stream（Redis 5.0+），推荐XADD cache:evict * key user_id 123+XREADGROUP，支持多消费者、ACK 和失败重放，比 list 更稳 - 关键点：本地缓存清掉 key 后，必须记录
last_evict_time[key]，下次轮询或收到指令时先比对时间戳，避免旧指令重复执行
本地缓存该不该自己管失效逻辑
绝大多数情况下，不该。除非你明确知道：1）QPS 极低；2）容忍分钟级脏数据；3）没有多实例部署。否则，把失效逻辑下沉到中间层（比如统一网关或缓存代理），比每个服务自己实现更可控。
- 常见翻车点：用
Time-based本地缓存（如Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES)）假装“自动失效”，结果 Redis 已更新，本地还扛着老值到超时 - 另一个坑是混淆「缓存穿透防护」和「失效通知」：布隆过滤器或空值缓存解决的是请求打穿问题，跟本地缓存要不要同步无关
- 最省事但易被忽略的一招：直接放弃本地缓存，用 Redis Cluster + pipeline + 连接池，99% 场景下延迟压根不输本地 Map，还省去所有同步逻辑
事情说清了就结束。
