关于利用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.可以利用缓存，自己写逻辑实现，还未提交的数据缓存下来，查询时先查询缓存