不能用 redis pub/sub 直接触发本地缓存失效，因其“发即忘”机制不保证消息可达，服务重启或网络抖动会导致指令丢失、缓存变脏；应改用 redis stream 实现可追溯、可重试、带 ack 的失效通道。
不能用 Redis Pub/Sub 直接触发本地缓存失效——它不保证消息可达，服务重启或网络抖动就会丢指令，本地缓存立刻变脏。这不是配置问题，是机制缺陷。
为什么 PUB/SUB 在多节点缓存失效场景下必然失败
Pub/Sub 是「发即忘」模型：消息不落盘、无重试、无消费者确认。Spring Cloud 多实例部署时，只要有一个节点在消息发出时恰好重启、GC 暂停过长、或订阅连接短暂断开，那条失效指令就永远消失了。
-
__keyevent@0__:expired事件同样不可靠：只响应自然过期，不响应DEL、SET、RENAME等主动操作，而业务中绝大多数缓存失效都是主动触发的 - 即使开启
notify-keyspace-events Ex，集群模式下事件只发到 key 所在 slot 的节点，客户端必须连对节点才能收到；而 Spring Cloud 实例通常使用 Lettuce 的 ClusterClient，自动路由后无法保证监听连接落在正确分片上 - Spring Data Redis 的
RedisMessageListenerContainer默认为每个 channel 启一个线程，动态增减 channel 时容易泄漏线程和连接，尤其在频繁上下线的云环境里
用 Redis Stream 替代 PUB/SUB 实现可追溯、可重试的失效通道
Stream 是 Redis 5.0+ 提供的持久化日志结构，天然支持消费者组、ACK 和消息重放，正好补足 Pub/Sub 的所有短板。
- 写操作端（如更新商品价格的服务）执行
XADD cache:evict * key product:1001 reason price_update，把失效指令写入 Stream - 每个 Spring Cloud 实例启动时创建独立消费者组成员，例如
XREADGROUP GROUP cache_evict_group instance-001 COUNT 1 STREAMS cache:evict > - 消费成功后必须调用
XACK cache:evict cache_evict_group <id></id>，否则该消息会持续出现在未 ACK 列表中，下次重连可继续处理 - 为防某实例长期宕机导致消息积压，可配合
XTRIM cache:evict MAXLEN 10000控制日志长度，但别设太小——10000 条足够覆盖数小时异常窗口
示例（Lettuce + Spring Boot）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
RedisCommands<string string> sync = connection.sync();
sync.xadd("cache:evict", Collections.singletonMap("key", "product:1001"));</string>
本地缓存清空前必须做幂等校验，否则旧指令会引发重复穿透
Stream 消息可能延迟到达，或因重试机制被多次投递。如果直接调用 caffeineCache.invalidate("product:1001")，在高并发下可能造成同一 key 被反复清除，触发多次 DB 查询。
- 每个节点维护一个本地
ConcurrentHashMap<string long></string>记录每个 key 最后一次收到失效指令的时间戳（用System.nanoTime()或毫秒级System.currentTimeMillis()） - 收到 Stream 消息后，先解析出指令中的时间戳（建议在
XADD时显式带上ts字段），比对本地记录；仅当新时间戳 > 旧时间戳时才执行invalidate() - 不依赖 Redis 服务端时间，避免集群时钟漂移；也不用引入分布式 ID 生成器，轻量可控
Spring Cloud 下的实际集成要点
不要让每个微服务自己管理 Stream 连接和消费逻辑——统一抽成 starter，由 @ConditionalOnClass(RedisStreamOperations.class) 控制自动装配。
- 消费任务必须用
@Scheduled(fixedDelay = 100, timeUnit = TimeUnit.MILLISECONDS)轮询，而非阻塞XREADGROUP，否则实例扩容时新节点无法及时加入消费者组 - 避免在
@EventListener或 WebMvc 的 Controller 里触发失效，这类入口不保证事务边界；应在 Service 层完成 DB 更新 + Stream 写入的原子性封装 - 若已有大量
@Cacheable注解，可自定义CacheManager包装器，在clear()时自动向 Stream 发送指令，而不是改业务代码
真正难的不是发消息，而是让每个节点都“确信自己没漏掉任何一条该执行的失效指令”。这需要放弃对 Pub/Sub 的路径依赖，接受 Stream 带来的额外复杂度——毕竟，缓存一致性从来就不是靠“广播一下”能解决的事。
