审批状态错乱之谜：并发覆盖下的数据库事务、MVCC与缓存一致性实战

1. 审批状态“倒带”了现象、复现和第一反应1.1 诡异状态同意之后又变回审批中在生产环境干过审批流的老哥应该都遇到过这种诡异场景明明数据库里的审批单已经走完业务方却拿着截图说状态是“审批中”再次点同意又提示“该单据已被处理”。我接手这个项目时第一反应是缓存过期时间设置不对但把 Redis 缓存无脑失效后问题依旧在特定并发窗口下复现。最后从事务和 MVCC 视角把整条链路拉通才发现真正作恶的不是缓存本身而是缓存更新时机和数据库快照读取叠加出来的并发覆盖。这个项目本身不算复杂一个 Spring Boot 服务MySQL 存储单据Redis 缓存审批链路的中间状态MyBatis 作为 ORM 框架。审批实例表wf_instance大概长这样CREATE TABLE wf_instance ( id BIGINT NOT NULL COMMENT 主键, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型, current_node VARCHAR(32) NOT NULL COMMENT 当前节点, status TINYINT NOT NULL COMMENT 0草稿 1审批中 2通过 3驳回 4撤销, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_biz_type_status (biz_type, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT审批实例表;并发覆盖的场景一般发生在多人同时处理同一张审批单时两个人同时在各自的工作台看到“待审批”A 点击通过B 点击驳回。按业务预期后提交的一方应当失败或者先提交的生效、后提交的给出“已被处理”的提示。但生产上是另一副面孔数据库状态一会儿是通过一会儿是审批中界面上的按钮和列表状态对不上。1.2 用 JMeter 把并发窗口打出来为了复现我用 JMeter 起了 5 个线程模拟 5 个用户同时针对同一个审批实例操作。接口动作分别是“通过”和“驳回”每次请求都带上审批实例 ID 和当前节点的审批意见。脚本跑了几轮之后数据果然开始乱同一张审批单通过接口返回成功驳回接口也返回成功。最终数据库里status的值取决于最后一个提交的事务而不是最后一个点击的人。更隐蔽的是有些请求在事务尚未提交、Redis 已更新时就被后一个线程读到了读到的又是旧状态。还有一类请求查询走的 MyBatis 缓存或 Redis 缓存读出来是“审批中”但数据库实际已经是“通过”。当时第一反应是并发量不够大调线程数到 20、50问题复现概率反而下降因为高并发下请求排队多了事务碰撞后直接报锁等待超时反而掩盖了逻辑覆盖。真正致命的是低并发、间隔几百毫秒到几秒的“温和并发”——这个窗口下两个事务都能提交成功却把一个状态字段来回踩。这个现象本身就是信号问题不在锁竞争而在更新条件和缓存读写机制上。1.3 第一次定位时走的弯路一开始定位方向是数据库锁。我一度以为有锁竞争随后抓了SHOW ENGINE INNODB STATUS也启用了performance_schema里的锁等待记录结果发现LOCK WAIT占比并不高。真正提交成功的两个事务之间没有出现互等的锁冲突。又怀疑是 Redis 缓存更新时序于是把所有写缓存的操作都调整到业务方法最后一行问题还是存在。后来我才意识到缓存更新在“方法最后一行”不等于“事务提交之后”。Spring 的Transactional方法事务提交发生在方法返回之后由代理对象统一处理。业务代码里最后一行写的缓存其实还在事务内——这时候数据库根本没提交其他事务如果读到缓存就会拿到一个“未来状态”而后续操作基于这个状态去做数据库更新自然就乱了。同样耗了不少时间的是 MyBatis 一级缓存和二级缓存。二级缓存默认没开一级缓存作用范围是 SqlSessionSpring 每次请求都新建 SqlSession 的话一级缓存影响有限。但一旦事务方法内部同一个 Mapper 方法调用多次比如先查询再更新再查询一级缓存会直接命中返回的是当前事务内第一次查到的旧值。当时不少诡异的状态回退就是它贡献的。2. 把事务边界和 MVCC 快照放到同一张图里看2.1 事务隔离级别不同看到的世界就不同要理解这个覆盖问题得先回到数据库事务的实际执行机制。MySQL InnoDB 默认隔离级别是 Repeatable ReadPG 默认是 Read Committed。两者对“事务内读取到的快照”定义完全不同。在 Repeatable Read 下事务内第一次普通SELECT会生成一个一致性读视图read view整个事务生命周期内后续普通SELECT都基于同一个视图。也就是说事务启动后即便其他事务提交了新状态当前事务通过普通查询看到的仍然是最初那个版本。这个机制就是 MVCC 的核心之一。Read Committed 则不同每条语句执行前都会生成新的 read view因此事务内多次查询可能看到不同版本的数据。很多开发同学以为“反正用 Read Committed/PG就能看到最新提交”这只对了一半——它是每条语句重新生成快照不是每条查询都实时读到未提交数据更不等于没有旧版本读取问题。回到审批场景。假设事务 T1 在 10:00:00 开始时读取status1事务 T2 在 10:00:01 提交status2。在 Repeatable Read 下T1 后续所有查询看到的仍然是自己事务开启时那个版本即status1。如果 T1 在 10:00:02 执行UPDATE wf_instance SET status3 WHERE id123它不会检查当前数据库里已经被 T2 更新成了 2而是直接把整行设置为 3。这就是典型的丢失更新本质是 write skew 的一种形态。2.2 数据库版本链与快照读取的真相InnoDB 每一行数据背后都有一条版本链。行记录里有隐藏的DB_TRX_ID记录最近一次修改该行的事务 ID还有DB_ROLL_PTR指向 undo log 中的上一个版本。执行UPDATE时InnoDB 会生成新版本并把旧版本链接到 undo log 上。普通查询通过 read view 判断可见性时会沿着版本链向后找直到看到一个符合规则的版本。这意味着即使某一行已经被并发事务改成status2只要当前事务的 read view 认为产生那个修改的事务不可见它找到的可能还是status1的旧版本。这个机制本身是为了并发读性能但副作用也很明显基于旧快照做“判断 写入”的组合操作时不加保护就会覆盖他人成果。很多人在分析并发覆盖时只盯着缓存忽略了数据库侧的 MVCC 也在放行旧值。其实缓存只是把旧状态提前暴露给了更多请求真正允许覆盖发生的是数据库更新语句没有追加任何条件判断。两条路径叠加形成了“读旧、写旧、盖新”的完整闭环。2.3 为什么慢事务更容易踩中这个坑从实践数据看触发覆盖的事务往往具备一个共同特征事务内有耗时的远程调用或者批量处理。常见情况是审批通过后需要调用外部系统同步数据同步接口响应慢拖长了事务的存活时间。事务活得越久其他并发事务完成提交的概率越大当前事务基于旧快照做更新的可能性也就越高。我还遇到过一种情况项目里用了读写分离主库负责写从库负责读。页面列表展示走从库详情接口走主库。主从同步延迟几百毫秒时业务人员看到的审批状态和实际状态错位再加上缓存又存了一份状态三层数据源各有各的时间点状态不一致被成倍放大。这类问题如果不先把数据库视角理清楚很容易被误判成简单的缓存覆盖。3. 缓存写错了位置从调用链里找到覆盖的真正时点3.1 缓存更新放在 commit 前等于对外广播了一个没提交的状态这是整个排查过程中最值得复盘的一段。最初的业务代码写着Transactional public void approve(Long id, String operator) { WfInstance instance wfInstanceMapper.selectById(id); // 省略前置校验 instance.setStatus(WfStatus.APPROVED); wfInstanceMapper.updateById(instance); redisTemplate.opsForValue().set(wf:instance: id, instance); }表面上看起来没毛病先改库再写缓存。但事务提交发生在方法返回之后redisTemplate.set执行时数据库事务还没有 commit。如果此时另一个线程发起驳回操作它读取 Redis 时发现状态已经是“通过”于是拿着这个并未持久化的状态去做了业务判断返回“该单据已通过不能驳回”。更麻烦的是另一个分支如果这个线程读到的缓存状态是“审批中”但数据库实际已经是“通过”它在事务内部又做了一次updateByIdMySQL 的写操作会在主键上对行加排他锁等前一个事务提交后后一个事务才有可能执行更新。虽然行锁保证了最终只有一个事务能修改这行但更新条件是updateById它只关注主键不关注状态字段于是后提交的事务会用自己事务里读到的旧状态覆盖前一个事务的成果。3.2 MyBatis 一级缓存和二级缓存带来的二次污染这个项目里二级缓存默认没开但一级缓存的问题被隐藏得很深。MyBatis 一级缓存是 SqlSession 级别的本地缓存默认开启。Spring 整合 MyBatis 后每个事务通常会绑定一个 SqlSession事务方法内同一个查询如果连参数都一样第二次执行会直接命中一级缓存不会发起数据库查询。这就出现了一个隐蔽场景事务 T1 先查询selectById(123)得到status1然后其他事务把数据库状态改成了 2T1 因为 Repeatable Read 快照看不到这个变更所以再次selectById(123)时一级缓存命中依然返回status1。此时如果用updateById把状态改成“驳回”因为更新语句只有主键条件不会校验当前行的真实状态覆盖就真实发生了。有人会说一级缓存不跨请求影响没那么大。但在这个项目里大量状态的判断不是直接查库而是走了一个ApprovalStatusService它先查 RedisRedis 不存在再查库查库后又写回 Redis。缓存链一长旧值被反复搬运最终覆盖问题的根因就散落在三处数据库事务快照、MyBatis 一级缓存、Redis 缓存。3.3 完整覆盖时序还原把两个并发请求拉通问题全貌是这样用户 A 发起“通过”事务 T1 开始读取实例 ID123状态为 1审批中。用户 B 发起“驳回”事务 T2 开始读取实例 ID123状态为 1。T1 执行业务逻辑调用外部系统成功后把 Redis 缓存更新为status2然后提交数据库。T1 提交成功数据库状态变为 2。T2 此时因为 MVCC 快照普通查询看到的仍是状态 1。它把 Redis 缓存更新为status3再执行UPDATE wf_instance SET status3 WHERE id123。T2 提交成功数据库状态被覆盖成 3驳回但用户 A 看到的界面还是“通过”。列表接口读 Redis发现状态是 3详情接口查库也显示 3两边一致但业务语义已经错了——正确的行为应当是 T2 不能执行成功因为审批单已经被 T1 处理了。这个时序里每一步单独看都“正常”T1 和 T2 都基于自己看到的状态做事数据库也没有死锁两个事务都提交成功。问题在于更新语句没有把“状态”纳入条件也没有使用版本号形成了典型的 last-write-wins 覆盖。4. 根因收敛不是“并发覆盖”三个字能讲完的4.1 并发覆盖的三种模式排查到这里我把并发覆盖拆成了三种模式第一种是缓存盲写覆盖。两个事务都把状态写进 Redis后写的覆盖先写的但后写不代表业务上后提交因为缓存更新时机和事务提交时机没有对齐。第二种是数据库盲更新覆盖。两个事务都读到status1各自执行UPDATE ... SET status2/3 WHERE id123。更新本身没有冲突检测后提交的覆盖先提交的属于典型的丢失更新。第三种是状态机跳跃覆盖。审批单从“审批中”只能流转到“通过/驳回/撤销”不应该出现“通过”变回“审批中”但盲更新让它出现了。状态机没有真正落地为数据库约束应用层也没有拦截。这三种模式各自有对应的解法缓存要在事务提交后失效或更新数据库更新要带乐观锁条件状态流转要在入口处做事件校验。只修其中一环都不够。4.2 为什么悲观锁只解决了部分问题排查过程中也有人提出SELECT ... FOR UPDATE或分布式锁一把梭的方案。加锁确实能把并发互斥掉让 T2 等 T1 提交后再继续但审批流里有很多操作不是只有同一把锁能覆盖的FOR UPDATE只能锁数据库行不一定锁得住 Redis 缓存里的状态。分布式锁要覆盖所有操作路径成本高而且容易影响吞吐。审批流程里还有“超时自动通过”“撤回重新提交”等后台任务它们如果不走同一把锁锁就形同虚设。如果操作频繁且耗时比如审批通过后调用外部系统同步锁等待时间会非常长最终损伤的是用户体验。最终我们没有选择悲观锁作为主要手段而是保留它作为数据库层面的兜底。真正解决问题的是一套组合拳先让缓存不再提前暴露未提交状态再让数据库更新具备冲突检测能力最后在应用层做状态机校验。4.3 修复原则让每一步都可验证、可回退修复的总原则是“用条件更新替代盲更新用缓存失效替代缓存覆盖”。核心有三条任何写操作必须基于“当前数据库真实状态”做条件更新而不是基于应用层读到的历史状态。任何缓存更新不能早于数据库提交最稳妥的方式是事务提交后直接删除缓存下次读取时再回填。状态变更必须符合预设流转规则非法流转直接拒绝。这三条原则看起来不复杂但落到代码层面需要动手术。下面展开讲。5. 修复落地缓存失效时机、乐观锁、状态流转校验5.1 从“先写缓存再提交”改为“提交后失效缓存”第一处手术是缓存策略。业务方法中不再主动更新 Redis改为在事务提交成功后删除缓存Transactional public void approve(Long id, String operator) { WfInstance instance wfInstanceMapper.selectById(id); // 校验当前状态是否允许审批通过 assertStatusTransition(instance, WfStatus.APPROVED); int updated wfInstanceMapper.updateStatusIfVersion(id, WfStatus.APPROVED, instance.getStatus(), instance.getVersion()); if (updated 0) { throw new BizException(审批单状态已变化请刷新后重试); } // 注册事务提交后的回调 TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { String key wf:instance: id; redisTemplate.delete(key); } }); }为什么用“删除”而不是“更新”因为删除简单可靠下次读取时从数据库加载最新值再回填更新则需要保证写入值就是数据库提交后的真实状态而这个值在事务里很难提前拿到尤其在更新涉及多个字段时。事务提交后删除缓存的写法依赖 Spring 的事务同步机制。registerSynchronization注册的回调会在事务真正提交后执行。如果事务回滚afterCommit不会触发缓存不会被污染。如果项目里没有使用 Spring 事务管理器也可以在主事务提交后显式清理缓存但那样容易漏代码还是用事务同步最省心。这里要特别强调不是所有项目都适合“提交后删缓存”。如果并发极高删除缓存后瞬间涌入大量请求都去查库可能打爆数据库。常见缓解手段是给缓存加非常短的过期时间比如 1 到 3 秒再配合删除操作。或者在删除之前把“新状态”写进一个短 TTL 的临时 key读不到主 key 时从临时 key 过渡。不过审批流这个场景并发远没有秒杀那么夸张直接删缓存就能撑住。5.2 给审批单加上乐观锁与状态条件更新第二处手术是数据库更新语句。原来updateById改成带版本号和状态条件的更新Update(UPDATE wf_instance SET status #{newStatus}, version version 1 WHERE id #{id} AND status #{oldStatus} AND version #{oldVersion}) int updateStatusWithLock(Param(id) Long id, Param(oldStatus) Integer oldStatus, Param(newStatus) Integer newStatus, Param(oldVersion) Integer oldVersion);核心逻辑是让数据库在更新前校验旧状态和版本号。如果另一个事务已经提交status或version不匹配影响行数为 0应用层就抛异常让用户重新查询最新状态。为什么版本号和状态条件都要因为状态条件能阻止状态机跳跃比如“已通过”被更新成“审批中”版本号能识别同状态下的重复更新比如两个人都把“审批中”改成“通过”第一个提交成功把版本从 0 变成 1第二个提交时版本还是 0更新失败避免重复审批通过。实际项目中如果字段比较多可以只更新需要变更的字段不要让整个对象参与更新。这样能减少锁范围和 undo log 开销也能避免把别的事务修改的字段误覆盖。这里还要补充两点第一UPDATE语句本身会加行锁两个并发事务同时更新同一行时后执行的一方会等待但等待结束后会因为版本号不匹配而返回 0不会覆盖第二UPDATE语句读到的status是数据库当前真实值不依赖应用的查询快照天然规避了 MVCC 带来的旧读问题。这也是建议用条件更新而不是“先查再比”的原因。5.3 状态流转校验把非法跨步骤操作挡在入口数据库条件更新能挡住覆盖但应用层还是要给出明确提示不能让用户看到“系统异常”。我在 Service 层加了一个状态流转换表private static final MapInteger, SetInteger TRANSITIONS new HashMap(); static { TRANSITIONS.put(WfStatus.DRAFT, Set.of(WfStatus.PENDING)); TRANSITIONS.put(WfStatus.PENDING, Set.of(WfStatus.APPROVED, WfStatus.REJECTED, WfStatus.CANCELED)); TRANSITIONS.put(WfStatus.APPROVED, Set.of(WfStatus.CANCELED)); TRANSITIONS.put(WfStatus.REJECTED, Set.of(WfStatus.PENDING)); } private void assertStatusTransition(WfInstance instance, Integer targetStatus) { SetInteger allowed TRANSITIONS.get(instance.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BizException(当前状态不允许执行该操作); } }这个转换表根据实际业务定制。比如“驳回”后可以“重新提交”“撤销”后可以“重新发起”不同企业审批语义不一样但要保证一点——状态不能跳跃到任意目标。配合数据库条件更新形成双重校验。边界情况也要考虑到。比如“重新提交”操作如果审批单已经被归档就不能再回到审批中比如审批人之前已经驳回再次提交需要更新节点信息并重置审批人这些业务动作和状态校验要放在同一个事务里不能拆开。5.4 问题数据的订正脚本生产环境已经出现脏数据除了改代码还要把错误状态修正回来。我写了一个只读的巡检脚本找出“当前状态和操作记录状态不一致”的审批单输出到告警平台再由运维确认后修正。SELECT i.id, i.status, a.operator, a.target_status, a.create_time FROM wf_instance i JOIN wf_approval_record a ON a.instance_id i.id WHERE a.id (SELECT MAX(a2.id) FROM wf_approval_record a2 WHERE a2.instance_id i.id) AND i.status a.target_status AND a.create_time DATE_SUB(NOW(), INTERVAL 1 DAY);这个 SQL 找出最后一次操作状态和当前状态不一致的实例。修正动作要谨慎我会先备份再按业务语义设置正确的最终状态。数据订正不是核心手段但能帮业务方先把眼前的问题解决掉。6. 上线后的验证与复盘经验6.1 JMeter 并发验证结果修复完成后我重新用 JMeter 压了一轮。场景还是 5 个用户并发操作同一张审批单但这次请求分布做了调整50% 的操作是“通过”50% 是“驳回”每个线程执行 100 次中间加 200ms 到 1s 的随机思考时间。压测结果符合预期两条并发请求同时到达时只有一个返回成功另一个返回“审批单状态已变化请刷新后重试”。数据库status不会出现从“通过”回退到“审批中”的情况。Redis 缓存中不会出现未提交的中间状态事务提交后缓存被正确清理。跑了 30 分钟没有一次死锁没有一次状态错误。有一点需要留意并发压测时有几个请求因为行锁等待出现了Lock wait timeout exceeded。这是因为UPDATE ... WHERE id? AND status? AND version?在并发极高时后一个事务会等待前一个事务的锁释放。如果前一个事务里有外部调用导致持锁时间过长等待会超时。我在压测里把外部调用放到了事务外或者改成异步回调才彻底解决这类问题。6.2 从一次故障里提炼的四条经验这次经历给我的收获远超“修好一个 bug”本身。第一条经验是缓存操作必须绑定事务生命周期写缓存不是简单的“放在方法最后一行”就完事而是要考虑数据库提交点。提交后失效缓存虽然多一次查库但换来的是强一致性值得。第二条经验是数据库更新必须有竞争检测。没有version和status条件任何并发控制都是空谈。这也是很多老项目改不动的原因——历史代码全是updateById想加条件发现影响面太大。但再难也得改尤其是核心状态字段。第三条经验是排查并发问题不能只盯锁。当时如果只去看死锁日志问题永远找不到。锁是互斥机制MVCC 是版本读取机制缓存是加速机制三者叠加之后的行为不能靠直觉推断得画时序图、打日志、一步步还原。第四条经验是状态机要显式建模。审批流这种业务天然是状态机如果不把允许的流转规则写清楚任何状态都可能被写入。加一个转换表维护成本极低却能挡住大量非法操作。6.3 如果你遇到类似问题建议按这个顺序排查如果你们的系统也出现缓存和数据库状态不一致我的建议是按照这个顺序排查第一先看数据库更新语句是否带条件。不带条件的updateById先修正这是根子上的问题。第二看缓存更新是否在事务提交之后。把业务方法里的缓存写操作改成事务提交后的缓存删除或者至少保证缓存写入值来自数据库提交后的结果。第三看事务内是否有耗时操作。外部调用、消息发送、批量计算全部挪到事务外缩短事务持锁时间。第四看是否存在多路径读取。列表接口走从库、详情接口走主库、缓存中间还可能插一脚多个数据源的短暂不一致会被业务感知为状态错乱。第五如果并发量真的很高再考虑分布式锁、Redis 原子操作等措施。但不要一开始就上锁锁解决的是互斥问题解决不了条件覆盖。6.4 关于分布式事务和缓存的延伸思考很多团队在碰到订单、库存、审批这类场景时想把缓存和数据库的一致性交给“分布式事务”来解决。这次实践让我更加确认一点分布式事务不是万能的它解决的是跨服务、跨数据源的一致性问题而审批流这种单服务内的事务核心是控制好数据库更新和缓存的时效性。如果后续服务拆分审批模块需要通过消息通知下游业务系统我会优先考虑本地消息表或事务发件箱模式在本地事务里写业务数据和待发送消息事务提交后再把消息发到 MQ消费方做幂等处理。这样做能避免“本地事务成功、MQ 发送失败”带来的数据不一致也比强一致分布式事务简单可靠。另外高并发下缓存设计还要考虑穿透、击穿、雪崩的问题。肯德基能承受的并发不等于审批流需要承受的并发量级不同方案选型也不同。别为了炫技引入一堆中间件能用数据库条件更新解决的优先在数据库层解决能用缓存失效解决的别做复杂的缓存双写。回到这次审批流故障最根本的一点就是状态是最核心的业务数据任何地方都不应该脱离数据库约束去独立演进。缓存是影子影子只能跟随实体不能反过来定义实体。把这个原则想明白了以后遇到类似的“并发覆盖”问题就不会再靠猜了。