一、前置基础JetCache 多级缓存模型要理解一致性问题首先要明确 JetCacheBOTH模式的底层结构它是两级缓存组合MultiLevelCache并非单一存储L1本地缓存基于 Caffeine 或 LinkedHashMap存储在当前 JVM 堆内存中读写无需网络开销性能极高但仅对当前 JVM 实例可见。L2远程缓存基于 Redis存储在远端服务器是所有 JVM 实例共享的数据源读写需要网络 IO但能保证多节点间的数据基准一致。默认读写逻辑读优先查 L1 → L1 命中直接返回 → L1 未命中查 L2 → 回填 L1 后返回。写/删先操作 L2 → 再操作 L1保证共享数据源优先更新。二、核心总览不一致的本质与场景差异JetCache 的不一致问题不是框架 Bug而是分布式系统 CAP 理论的必然取舍不同部署场景的一致性级别完全不同部署场景一致性级别核心风险解决方案多节点集群最终一致Eventual Consistency跨 JVM 本地缓存无法感知变更、广播延迟/丢失开广播失效 短本地 TTL 核心场景弃用本地缓存单节点单机准强一致Quasi-Strong Consistency仅毫秒级瞬态窗口、配置错误TTL 倒挂严格遵守localExpire remoteExpire强一致场景库存/余额/价格不满足本地缓存副本导致脏读、并发操作原子性问题纯远程缓存 Lua 脚本 版本号校验三、多节点集群为什么必然存在不一致3.1 根本原因本地缓存是跨 JVM 的「数据孤岛」多节点部署时每个 JVM 都有自己的独立 L1 缓存彼此完全不可见请求打到节点 A触发Cacheduser:1张三写入 A 的 L1 RedisL2。后台更新操作路由到节点 A执行CacheInvalidateA 清空自己的 L1 更新 Redis 为user:1李四。用户再次访问请求被负载均衡到节点 BB 的 L1 仍存在user:1张三直接返回旧值。此时RedisL2是正确的但部分节点的 L1 是永久脏数据直到本地 TTL 过期。3.2 JetCache 的缓解方案Redis Pub/Sub 广播失效为解决跨节点失效问题JetCache 提供了syncLocal broadcastChannel机制当任意节点执行put/remove/update时除了操作 Redis还会通过Redis Pub/Sub发送一条缓存失效消息。集群内所有节点订阅该 Channel收到消息后立即删除本地对应 Key 的缓存。⚠️ 但该方案仍然是最终一致无法消除不一致窗口原因如下网络延迟消息从发送到接收存在几十~几百毫秒的延迟这段时间内其他节点仍会命中旧值。消息丢失风险Redis Pub/Sub 不保证消息持久化连接闪断、Redis 主从切换都会导致消息丢失如果自定义了 Redisson 编解码器如JsonJacksonCodec还会导致消息反序列化失败等于失效通知完全失效。消费延迟JVM 处理订阅消息需要排队高负载下可能出现秒级延迟。3.3 多节点下必踩的 5 个坑TTL 倒挂localExpire本地 TTLremoteExpireRedis TTL。Redis 数据过期后本地缓存成了无源之水永远无法更新直到本地 TTL 到期。Key 定义不一致Cached、CacheInvalidate、CacheUpdate的area/name/key不匹配比如 SpEL 表达式写法不同导致清了错误的 Key 或没清到。AOP 失效缓存注解用在 private 方法、同类方法内部调用、Async/Transactional异常传播场景导致注解未被 Spring AOP 拦截缓存未清理。广播配置遗漏未配置broadcastChannel或syncLocalfalse等于完全没开跨节点失效。非标准更新路径直接改 DB 不碰缓存、只改 Redis 不改 DB导致缓存与 DB 基准都不一致。四、单节点单机为什么基本一致单节点部署时最大的「跨 JVM 通信」障碍消失JetCache 可以在同一个 JVM 内完美协调 L1 和 L2 的操作不存在物理数据不一致。4.1 核心保障JVM 内的同步操作顺序JetCache 的所有缓存操作都是同步顺序执行没有并发隔离问题写操作先写 L2Redis→ 再写 L1本地保证共享数据源优先更新本地只是镜像。删操作先删 L2 → 再删 L1保证外部请求先无法读到旧值再清理内部副本。读操作先查 L1 → 未命中查 L2 → 回填 L1保证 L1 永远是 L2 的最新镜像。4.2 仅存的瞬态不一致场景可自愈不影响业务单节点下唯一可能出现的不一致是毫秒级瞬态窗口不会造成永久脏数据JVM 崩溃中断刚写完 L2、还没更新 L1 时服务宕机重启后 L1 随 JVM 销毁下次读取会从 L2 加载新值完全自愈。并发竞态线程 A 执行删除已删 L2 但未删 L1 时线程 B 抢先读了 L1 旧值仅持续毫秒级绝大多数业务可忽略。配置错误唯一人为风险localExpire remoteExpire导致 Redis 过期后本地仍返回旧值这是单节点下唯一会造成永久脏数据的情况严格遵守localExpire remoteExpire即可完全避免。五、强一致要求场景的定制方案核心新增如果业务是高并发库存扣减、实时价格/账户余额、权限信息等对脏读零容忍的场景默认的 BOTH 模式完全不满足要求必须定制方案5.1 场景一高并发库存扣减/优惠券核销特点并发极高、不允许超卖、不允许脏读性能和安全同等重要。❌ 禁用方案默认 BOTH 模式、本地缓存存库存值、非原子性更新。✅ 落地方案纯 REMOTE 模式 Lua 原子脚本 双删兜底弃用本地缓存缓存类型改为typeREMOTE所有读都走 Redis从根源上消除本地副本不一致问题。原子性扣减库存扣减必须用 Redis Lua 脚本保证「查询库存→校验库存→扣减库存」的原子性避免并发超卖-- 库存扣减Lua脚本KEYS[1]为库存keyARGV[1]为扣减数量if(redis.call(exists,KEYS[1])1)thenlocalstocktonumber(redis.call(get,KEYS[1]));if(stocktonumber(ARGV[1]))thenredis.call(decrby,KEYS[1],ARGV[1]);return1;-- 扣减成功endendreturn0;-- 库存不足分布式锁兜底Lua 脚本执行失败时用 Redisson 分布式锁串行化处理防止缓存击穿打爆 DB。写后双删更新库存时走「先更 DB → 再删 Redis → 延迟 1s 再删一次」的旁路模式应对并发读写导致的脏数据写回问题。5.2 场景二实时价格/账户余额/权限信息特点对数据准确性要求极高但读 QPS 也很大完全不用本地缓存会压垮 Redis。✅ 折中方案本地缓存 版本号校验 短 TTL缓存结构调整把缓存值改为{data: 实际业务数据, version: 递增版本号}版本号随数据更新单调递增。读流程① 先查本地 L1拿到{data, version}② 同步/异步查 Redis 中该 Key 的最新 version③ 若本地 version ≥ Redis version直接返回本地 data否则从 Redis 加载最新数据回填 L1。写流程① 更新 DB生成新 version② 更新 Redis 中的{data, newVersion}③ 开syncLocaltrue broadcastChannel广播清所有节点的 L1。兜底本地 TTL 设为 1~5s即使版本号校验失效最多 5s 后自动过期加载新值。✅ 增强方案把 version 单独存一个 Redis Key仅用来做一致性校验减少数据传输量。5.3 场景三普通低频配置/非核心数据特点允许秒级不一致读 QPS 高追求性价比。✅ 方案BOTH 模式 syncLocal 短 localExpire直接用 JetCache 默认多级缓存localExpire设为 1~5sremoteExpire设为 30~60s开广播失效即可无需额外开发。六、生产级配置与最佳实践6.1 完整 jetcache.yml 配置模板可直接抄jetcache:statIntervalMinutes:15# 统计间隔输出缓存命中率日志用于监控area:default:# -------------------------- 多节点集群通用配置 --------------------------type:both# 本地远程多级缓存local:type:caffeine# 本地缓存类型Caffeine性能最优limit:10000# 最大缓存条目数防止OOMexpireAfterWriteInMillis:2000# 本地TTL2秒远小于远程TTLsyncLocal:true# 开跨节点本地缓存失效remote:type:redis.lettuce# 推荐Lettuce响应式支持更好也可选redissonkeyConvertor:fastjson# 不要用自定义编解码器避免广播消息反序列化失败expireAfterWriteInMillis:30000# 远程TTL30秒broadcastChannel:jetcache_invalidate_channel# 广播失效通道必须配# Redis连接配置host:127.0.0.1port:6379password:database:0poolConfig:minIdle:5maxTotal:20# -------------------------- 强一致场景库存/余额配置 --------------------------# type: remote # 只用远程缓存完全禁用本地缓存# remote:# type: redis.lettuce# keyConvertor: fastjson# expireAfterWriteInMillis: 30000# # 强一致场景不需要广播配置因为根本没有本地缓存6.2 注解使用规范避免 90% 的坑Cached、CacheInvalidate、CacheUpdate必须使用相同的area、name、key定义Key 的 SpEL 表达式要完全一致避免清错 Key。注解只能用在public 方法上且不能通过同类方法内部调用Spring AOP 生效要求不要在Async、Transactional自定义超时/传播行为的方法上使用缓存注解避免事务未提交就清缓存。高并发读场景加CachePenetrationProtect防止缓存击穿多个线程同时请求同一个 Key 时只有一个线程去加载 DB其余线程阻塞等待。更新数据严格走「先更 DB后清缓存」的标准旁路模式禁止「先清缓存再更 DB」避免并发下脏数据写回。6.3 TTL 配置铁律永远保证localExpire remoteExpire本地 TTL 就是愿意容忍的最大不一致窗口。强一致场景localExpire 设为 1~5s非核心场景最多不超过 10s。remoteExpire 根据业务更新频率设置核心数据 30~60s静态数据如类目可设 10~30min。七、兜底与监控监控缓存命中率JetCache 每statIntervalMinutes输出命中率日志若本地命中率过高但远程命中率低说明广播失效或 Key 定义不一致需排查。定时一致性校验非核心数据可开定时任务随机抽查本地缓存和 Redis 的值是否一致不一致则主动清本地缓存。降级预案Redis 故障时本地缓存可临时作为只读缓存但要关闭写操作避免脏数据扩散Redis 恢复后清空所有本地缓存重新加载。异常告警监控 broadcastChannel 的消息发送/接收成功率低于 99.9% 触发告警排查 Redis 连接或编解码器问题。八、最终总结JetCache 的 BOTH 模式是「性能优先、最终一致」的设计天生不适合库存、余额等强一致场景不要强行使用。多节点集群的不一致是分布式系统的必然结果只能通过缩短 TTL、开广播来降低影响无法完全消除。单节点单机的不一致是可忽略的瞬态问题只要配置正确就不会有永久脏数据。强一致场景必须放弃本地缓存或用版本号校验兜底核心操作要靠 Redis Lua/分布式锁保证原子性。