这个方案基于MQ来保证消息事务的最终一致性，还算是一个比较合理的解决方案，只要保证MQ的可靠性就可以正常实施应用，业务消费方根据本身的消息重试达到最终一致性。
框架
以上说的都是理论和自己实现的方式，那么分布式事务就没有框架来解决我们的问题吗？
有，其实还不少，但是没有能扛旗者出现，要说有，阿里的开源框架Seata还有阿里云的GTS。
GTS（Global Transaction Service 全局事务服务）是阿里云的中间件产品，只要你用阿里云，付钱就可以用GTS。
Seata（Simple Extensible Autonomous Transaction Architecture）则是开源的分布式事务框架，提供了对TCC、XA、Saga以及AT模式的支持。
那么，GTS和Seata有什么关系呢？
实际上最开始的时候他们都是基于阿里内部的TXC（Taobao Transaction Constructor）分布式中间件产品，然后TXC经过改造上了阿里云就叫做GTS。
之后阿里的中间件团队基于TXC和GTS做出了开源的Seata，其中AT（Automatic Transaction）模式就是GTS原创的方案。
至于现在的版本，可以大致认为他们就是一样的就行了，到2020年，GTS已经全面兼容了Seata的 GA 版本。
整个GTS或者Seata包含以下几个核心组件：
Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
无论对于TCC还是原创的AT模式的支持，整个分布式事务的原理其实相对来说还是比较容易理解。
事务开启时，TM向TC注册全局事务，并且获得全局事务XID
这时候多个微服务的接口发生调用，XID就会传播到各个微服务中，每个微服务执行事务也会向TC注册分支事务。
之后TM就可以管理针对每个XID的事务全局提交和回滚，RM完成分支的提交或者回滚。
AT模式
原创的AT模式相比起TCC的方案来说，无需自己实现多个接口，通过代理数据源的形式生成更新前后的UNDO_LOG，依靠UNDO_LOG来实现回滚的操作。
执行的流程如下：
TM向TC注册全局事务，获得XID
RM则会去代理JDBC数据源，生成镜像的SQL，形成UNDO_LOG，然后向TC注册分支事务，把数据更新和UNDO_LOG在本地事务中一起提交
TC如果收到commit请求，则会异步去删除对应分支的UNDO_LOG，如果是rollback，就去查询对应分支的UNDO_LOG，通过UNDO_LOG来执行回滚
TCC模式
相比AT模式代理JDBC数据源生成UNDO_LOG来生成逆向SQL回滚的方式，TCC就更简单一点了。
TM向TC注册全局事务，获得XID
RM向TC注册分支事务，然后执行Try方法，同时上报Try方法执行情况
然后如果收到TC的commit请求就执行Confirm方法，收到rollback则执行Cancel
XA模式
TM向TC注册全局事务，获得XID
RM向TC注册分支事务，XA Start，执行SQL，XA END，XA Prepare，然后上报分支执行情况
然后如果收到TC的commit请求就执行Confirm方法，收到rollback则执行Cancel