大事务问题通常是说,在一个方法的逻辑中,执行的业务逻辑较多,导致接口响应时间较慢等带来的问题,那我在线上碰到的问题是这样子的:
线上系统交互逻辑
我自己的系统是A系统,我的下游是B系统
1.A系统对上游提供了创建订单的接口createOrder()
2.我的接口中,会先进行一系列规则校验,校验完成之后,通过dubbo接口调用B系统的接口
3.调用B系统的接口之后,会接着进行数据库的更新以及其他的业务逻辑的执行,最后再提交事务
上面这三个步骤是我自己接口中做的事情,是在一个大的事务方法中
4.B系统在接收到我的请求之后,自己处理完之后,会发送一个mq消息给我的A系统
5.A系统在接收到mq消息之后,会调用updateDateTimer()方法,这个方法中,依赖createOrder()接口中对数据库字段更新的信息
出现的问题
此时出现的问题是:B系统的消息回调,先于A系统中createOrder()方法事务的提交,那此时就有问题了,在updateDateTimer()接口中,取到的是更新之前的值,那此时问题就大了,下游一直存储的是更新之前的值
问题分析
我们把水平方向,想象为一个时间轴,那按照我们设想的逻辑,在提交事务之后,再接收到消息回调,此时就没后问题了,收到消息回调的时候,在updateDateTimer()方法中,取到的就是事务提交之后的值,但是实际出现问题的时候,并不是这样子的