JetCache多节点本地缓存失效问题分析与解决方案

问题背景

在使用JetCache构建分布式缓存系统时，开发人员经常会遇到多节点环境下本地缓存同步失效的问题。具体表现为：当一个节点更新了缓存数据后，其他节点的本地缓存未能及时失效或更新，导致数据不一致的情况。

典型场景

在Spring Boot 3.3.0、JetCache 2.7.7和Redisson 3.35.0的组合环境中，开发人员配置了CacheType.BOTH（两级缓存）并启用了syncLocal=true，期望实现本地缓存和远程缓存的双层缓存机制，同时保持多节点间的缓存同步。然而实际运行中发现，当一个节点更新缓存后，其他节点的本地缓存并未按预期失效。

配置分析

典型的配置如下：

jetcache:
  statIntervalMinutes: 1
  areaInCacheName: false
  local:
    default:
      type: caffeine
      keyConvertor: fastjson2
      limit: 100
  remote:
    default:
      type: redisson
      redissonClient: redissonConfig
      broadcastChannel: ba-ad-broadcast
      keyConvertor: fastjson2
      defaultExpireInMillis: 10000
      keyPrefix: 'xxxx'

同时Redis配置了notify-keyspace-events: Egx$以启用键空间通知功能。

问题根源

经过深入分析，发现问题的根本原因在于Redisson的编解码器配置。当开发人员自定义了Redisson的编解码器（如JsonJacksonCodec）时，会导致JetCache的广播通知机制失效。

具体技术细节：

1. JetCache通过RedissonBroadcastManager实现多节点间的缓存失效通知
2. RedissonBroadcastManager.startSubscribe()方法内部使用字节数组(byte[])作为监听消息的格式
3. 当使用自定义编解码器时，消息格式可能不匹配，导致监听器无法正确解析失效通知

解决方案

1. 使用默认编解码器：最简单的解决方案是移除自定义的编解码器配置，让Redisson使用默认的编解码器。这确保了广播消息能够被所有节点正确解析。

2. 统一编解码配置：如果必须使用自定义编解码器，需要确保所有节点的编解码配置完全一致，并且能够正确处理字节数组格式的消息。

3. 验证配置：在应用启动后，可以通过以下方式验证配置是否生效：

   • 检查Redis的pub/sub通道是否有消息流通
   • 监控本地缓存的失效日志
   • 使用缓存统计功能观察命中率变化

最佳实践建议

1. 环境一致性：确保所有节点的JetCache和Redisson配置完全一致，特别是编解码器和序列化相关的配置。

2. 监控机制：实现缓存一致性的监控机制，定期检查各节点的缓存数据是否一致。

3. 测试验证：在开发环境中模拟多节点场景，验证缓存失效机制是否按预期工作。

4. 超时设置：合理设置本地缓存的超时时间，作为广播失效机制的补充保障。

总结

JetCache的多节点缓存同步是一个强大的功能，但需要正确配置才能发挥作用。Redisson编解码器的选择直接影响广播通知的有效性。通过理解底层机制并遵循最佳实践，可以构建出高效可靠的分布式缓存系统。当遇到类似问题时，建议从消息传输的基本格式入手排查，往往能够快速定位问题根源。