多级缓存Redis怎么与Caffeine同步_发PubSub清空本地-Redis-PHP中文网

PubSub清空本地缓存易失效，因Redis不保证消息可达、无ACK、断连丢消息；需通过TTL兜底、主动校验、removal监听告警及正确invalidate调用保障可靠性。

多级缓存redis怎么与caffeine同步_发pubsub清空本地

直接用 Redis 的 PUB/SUB 通知所有节点清空 Caffeine 缓存，是最轻量、最低侵入的同步方式之一，但实际落地时很容易掉进「消息丢失」「重复消费」「本地缓存没清干净」这几个坑里。

为什么 PubSub 清空本地缓存容易失效？

Redis 的 PUB/SUB 是纯内存广播，不保证消息可达：订阅断开期间发布的消息彻底丢失；客户端重启后也不会重放；没有 ACK 机制，发了就完事。这意味着，只要某个服务实例短暂 GC、网络抖动或部署中，它就收不到那条 cache:invalidate:user:1001 消息，Caffeine 里的旧数据就会一直残留。

另外，Spring Boot 默认的 RedisMessageListenerContainer 在监听器抛异常时会静默跳过该消息，不会重试——你根本不知道哪条清空指令被吞了。

不要依赖单次 PUBLISH 就认为本地缓存已同步
避免在监听器里做耗时操作（比如远程调用），否则阻塞线程池会导致后续消息积压甚至丢弃
别用通配符模式（PSUBSCRIBE cache:*）监听大量 key，Redis PubSub 的 pattern match 性能随订阅数线性下降

怎么让 PubSub 清空真正可靠？

核心思路是「补漏 + 确认 + 降级」：不指望一次 pub 就搞定，而是用短期 TTL + 主动探测 + 最终兜底来覆盖各种异常场景。

发送清空指令时，除了 PUBLISH cache:invalidate:user:1001，顺带 SET cache:invalidate:user:1001 "" EX 60，给一个 60 秒的兜底标记
Caffeine 配置 expireAfterWrite(5, TimeUnit.MINUTES)，哪怕某次清空失败，最多 5 分钟后也会自然过期
在 Caffeine 的 removalListener 里记录日志，一旦发现是因「EXPIRED」或「REPLACED」被移除，说明清空指令可能没生效，可触发告警
关键业务读取前加一层校验：先查 Caffeine，命中后检查对应 key 在 Redis 中的版本号（如 user:1001:version），不一致则强制 reload 并清空本地

监听端代码必须避开的三个写法

很多项目直接在 MessageListener 里调 caffeineCache.invalidate(key)，看似没问题，实则埋雷：

错误写法：cache.invalidate(key.toString()) —— 如果 key 是对象，toString() 结果和 Caffeine 实际存的 key 不一致，清空失败
错误写法：cache.asMap().remove(key) —— 绕过 Caffeine 的统计和监听机制，RemovalListener 不触发，监控指标失真
错误写法：监听器方法上加 @Transactional —— PubSub 不在事务上下文里，这个注解完全无效，还可能引发 AOP 代理混乱

正确做法始终用 cache.invalidate(key)，且确保传入的 key 类型和存入时完全一致（推荐统一用 String 或自定义 CacheKey 对象并重写 equals/hashCode）。