在日常开发过程中,时常会遇到一个如下场景:
- 根据条件x,读取表A,得到多行数据;
- 遍历读取到的数据,对条件x以外的字段进行修改,并进行保存;(重点)
- 修改后,调用通用方法,传入条件x,重新读取表A的数据,并进行MQ广播;
流程如下图
业务代码MybatisMQ开启事务第一次查询S1条件x查询返回查询结果R1更新修改查询结果R1批量更新更新成功第二次查询S2条件x查询返回查询结果R2发送MQ结果R2发送MQ提交事务业务代码MybatisMQ
以上业务流程,是一个很普通的流程,一眼看去没什么问题,以下是我们期望的流程结果:
- 第一次条件x查询,得到结果R1;
- 修改R1后执行更新;
- 第二次条件x查询,得到结果R2为更新后在当前事务中的最新数据;
但是在我们实际测试中,却发现,对于相同的条件x的前后两次查询S1和S2,得到的居然是一样的结果数据。若按照以上的业务流程,第二次查询后发送MQ,如果R2不是最新值,那么可能导致MQ消费者数据不一致的情况。
下面来看一下伪代码演示。
示例演示
以下伪代码中,为了方便演示,不进行MQ操作,直接使用打印日志代替
可以看到,在执行Mybatis-Plus提供的批量更新方法updateBatchById后,重新读取数据,居然还是更新前的数据,那这到底是怎么回事呢,我们往下分析与追踪。
分析与追踪
在这个案例中,只有查询-更新-查询的代码,数据库使用的是MySQL,ORM框架使用的是Mybatis-Plus,所以可以从以下两方面进行排查
- MySQL事务;
- MyBatis-Plus;
mysql事务
知识点A:在MySQL中,Innodb基于MVCC思想实现快照读。核心思想是利用事务的ReadView与undo log版本链进行匹配,从而判断当前事务能读取到哪个版本的数据。即,在Innodb的默认隔离级别为可重复读时,对于同一事务下,写操作的结果对下一个读操作是可见的。
回到上面的案例代码,可见,当前代码的“读-写-读”操作,是被包含在同一个事务中,事务管理完全交给Spring事务管理器,且并未对事务传播行为进行控制,所以按照MySQL的知识点,可以确定,第二次“读”操作,如果是正常从MySQL数据库进行读数据,那么得到的数据必然是“写”操作所产生的数据。
但是事实却恰恰相反,第二次“读”操作,无法得到前一次“写”操作产生的数据。由此,我们有理由怀疑,第二次”读“操作,可能存在没有执行MySQL读取操作的情况,为此,我们开启SQ