关于利用MQ实现分布式事务的想法【转】

转自:https://www.jianshu.com/p/bafb09954f18

假设:消息服务不丢消息

场景 服务A 服务B 服务C 消息服务Q

伪代码

服务A中
transaction{
A本地事务
B.callB();
C.callC();
A本地事务
}

利用消息服务来实现分布式事务
原理 当服务A执行事务时,所有指定远程调用会被转换为发送一条调用消息到消息服务,当B和C接收到消息时,立即执行消息指定的方法,并在提交前发送回复消息给A(携带有返回值)并且等待接收提交或者回滚消息,服务A执行完方法也在提交前等待B和C的回复,当B和C的回复都为sucess时发送提交消息给B和C,然后自己提交,否则回滚。B和C接到提交消息后,提交,否则回滚。

异常情况一:在发送调用B的消息时失败
服务A事务直接回滚

异常情况二:在发送调用C的消息时失败
服务A事务直接回滚,并发送回滚消息到指定队列(此两步操作由Q的事务消息保证原子性)

异常情况三:服务A提交和回滚失败
由于服务A提交和回滚操作和发送提交或者回滚消息在一个事务内,所以放在一起讨论,
由于此部分由消息中间件保证原子性,固提交或者回滚失败,不会有提交或者回滚消息到达消息中间件,B和C等待一段时间后自动回滚

异常情况四:B在发送回复消息时失败
A在等待指定时间后没有收到B的回复,进行回滚操作并发送回滚消息到指定队列,C在收到回滚消息后回滚,B在等待指定时间后没有收到A的提交消息回滚

异常情况五:C在发送回复消息时失败
同异常情况四

异常情况六:B提交失败或者C提交失败
B或C中调用消息和提交消息均不消费,会进行重试

异常情况七:B或者C回滚失败
同异常情况六

异常情况八:B或者C逻辑出现异常导致失败
B或者C直接回滚,并且发送失败回复

停机启动恢复处理

由于异常导致的死机,然后重启后的逻辑

一、只接收到调用消息,执行,然后等待固定时间后回滚。
二、按照顺序接收到调用消息和提交消息,执行然后提交
三、先接收到提交消息后接收到调用消息,一样,执行然后提交
四、接收到调用和回滚消息,同上

从上可以推导出,利用消息系统做分布式事务的两个特性
强调一下假设:消息服务不丢消息
一、在网络畅通所有服务高可用的情况下,可以做到数据的强一致性
二、在网络和服务可能存在故障的情况下,可以做到数据的最终一致性

关于数据在最终一致性情况下的查询问题
1.最好的解决方案是不管,更新后查询数据查到旧的数据就让它查到旧的数据
2.可以利用缓存,自己写逻辑实现,还未提交的数据缓存下来,查询时先查询缓存

猜你喜欢

转载自www.cnblogs.com/tinyj/p/9926734.html