RLocalCachedMap 事务提交成功了,其他节点却还读到旧值?一个被忽视的广播时序陷阱

RLocalCachedMap 事务提交成功了,其他节点却还读到旧值?一个被忽视的广播时序陷阱【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson压测里一个订单扣减请求:事务commit()返回成功,GET主库的值已经是 99,可同一集群另一台机器用RLocalCachedMap读,拿到的还是 100。更糟的是,有人在事务里顺手调一句localCachedMap.clearLocalCache(),直接炸出UnsupportedOperationException。反直觉的是,这两个问题根子是同一个——Redisson 的本地缓存失效广播,压根没跟上事务的提交节奏。最小复现:一行调用就崩,一个时序就旧复现路径很短,两台节点连同一个 Redis,共享一个RLocalCachedMap:RTransaction tx redisson.createTransaction(TransactionOptions.defaults()); RLocalCachedMapString,Integer m tx.getLocalCachedMap(stock); m.put(p1, 99); // 走事务内存队列,没碰 Redis tx.commit(); // 此刻才真正写库并释放锁 m.clearLocalCache(); // 事务对象上直接抛 UnsupportedOperationException这不是 bug,而是两个机制在设计上的时序错位:事务把写操作攒在客户端队列里,本地缓存却指望每次落库都收到一条广播消息,两者交汇的先后顺序没对齐。机制拆解:事务攒队列,缓存靠广播先把它想象成两个咬合的齿轮,一个管什么时候写库,一个管写完之后通知谁。机制A:Redisson 事务在做什么Redisson 的事务隔离级别是READ_COMMITTED,白话就是:你填完表单还没点提交,隔壁工位看不到你写了什么。commit()之前,所有put/remove只堆在客户端的操作队列里,同时对写键加锁;commit()那一刻队列才批量下发到 Redis,锁也在提交或回滚后才释放(具体超时字段以docs/transactions.md为准)。机制B:RLocalCachedMap 在做什么本地缓存不直接查库,它靠一条 pub/sub 广播通道保鲜。SyncStrategy三档:INVALIDATE广播 16 字节键哈希让各节点删本地条目(默认),UPDATE广播完整键值对直接覆盖本地,NONE不广播、只靠 TTL 过期。交汇点在哪关键在谁先谁后、谁通知谁:本地缓存的失效广播,只由实际写库的那个动作触发。而事务在commit()前根本没写库——它把写操作锁在客户端队列里。于是出现两个断层:一是事务对象上的clearLocalCache、preloadCache、destroy被明确禁用(见RedissonTransactionalLocalCachedMap),一调就抛异常;二是提交瞬间广播发出去,其他节点的本地缓存是异步收到并失效的,提交返回到广播送达之间有一段肉眼看不见的时间差,这段窗口里读到的就是旧值。修复路径:从改配置到调架构按侵入性从低到高走,不是让你全上,而是挑一层够用就停。零代码改动:SyncStrategy 与 ReconnectionStrategy 配置不动业务代码,只调getLocalCachedMap的选项,把失效策略从默认收紧:LocalCachedMapOptionsString,Integer opt LocalCachedMapOptions.defaults() .syncStrategy(SyncStrategy.UPDATE) // 广播完整值,缩短旧值窗口 .reconnectionStrategy(ReconnectionStrategy.CLEAR); RLocalCachedMapString,Integer cache redisson.getLocalCachedMap(stock, opt);适用判断:如果你的读写都在同一个 Redisson 实例内、只是偶尔读到过期值,选这一层就够。少量代码:运行时显式失效真正卡住的地方往往是提交后没主动收口。别在事务对象上调本地缓存方法(会抛异常),拿到事务外的同名 map 实例再失效:RLocalCachedMapString,Integer live redisson.getLocalCachedMap(stock, opt); RTransaction tx redisson.createTransaction(TransactionOptions.defaults()); RLocalCachedMapString,Integer tm tx.getLocalCachedMap(stock); tm.put(p1, 99); tx.commit(); // 先落库 live.clearLocalCache(); // 提交后用非事务实例收口,清掉本地旧值适用判断:如果你的写节点就是读节点自己,提交后立即clearLocalCache能抹掉本机残留,这一层就够。架构层:写路径绕过本地缓存换个角度看,本地缓存天然是最终一致的读加速层,不该承担强一致写的职责。根治思路是把扣减库存这类强一致操作从本地缓存的写路径里拆出去:本地缓存只做读加速,写走独立强一致对象(如带版本校验的RBucket或分布式锁),提交后再让缓存失效。适用条件是写读分离、能接受写路径不走本地缓存。适用判断:如果是多节点高并发写同一批键,别指望缓存层兜底,把写路径独立出来才是正解。选型速查:默认推荐维度低侵入(配置)中侵入(运行时)高侵入(架构)一致性弱,靠广播窗口收敛中,提交后主动失效强,写读分离改动量仅选项加几行提交后收口拆写路径适用单实例、读多写读同节点多节点并发写默认推荐:先上低侵入的配置层,把syncStrategy提到UPDATE;仍读到旧值,再加运行时提交后收口;只有并发写同一批键时才动架构层。别一上来就改架构。验证与边界:一条命令看穿窗口验证很简单:开两个终端连同一 Redis,节点A提交扣减,节点B立刻循环读并打印时间戳,统计提交返回到读到新值的间隔。这个间隔就是广播窗口,UPDATE比INVALIDATE短,因为前者直接下发值、后者还得等删除再回源。边界要诚实说清:这套修复消除的是提交后本地缓存读到旧值的冲突,但它做不到把广播窗口压到零——只要还在用 pub/sub 异步失效,提交和送达之间永远有一小段窗口。如果你的业务要求读节点在提交后立即拿到新值(强一致读),本地缓存这条路本身就选错了,得回到架构层把强一致读从本地缓存里拿掉。回到开头那台读到 100 的机器:根因不是事务失败,而是失效广播比提交慢了一拍。下次再遇到主库对、本地错,先查你读的那个 map 是不是事务对象、再查syncStrategy是不是还停在默认档,基本就能定位到这条时序线上。【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考