分布式事务的解决方案

只要是微服务项目都有可能发起远程调用，发起远程调用就会存在分布式事务。

你们采用的哪种分布式事务解决方案？

1. 1. Seata框架（XA，AT，TCC）
   2. MQ

1. Seata解决分布式事务

Seata事务管理中有三个重要的角色：

TC（Transaction Coordinator）事务协调者：事务的协调者需要单独部署。

TM（Transaction Manager）事务管理器：

RM（Resource Manager）资源管理器：每一个微服务。每一个微服务也叫分支事务。

1.1. XA模式

等所有的事务执行都成功再提交事务。保证的是强一致（CP模式）

TM开启全局的事务，来调用分支事务，让每一个分支事务注册到TC上，各个微服务去执行自己的SQL，但是并没有提交事务，要向TC报告自己的事务状态给TC ，这样TC就能够知道自己的业务状态了。TM来提交或者回滚事务，但是提交或者回滚事务之前需要检查各个分支事务的状态，由TC通知各个微服务来提交或回滚事务就行了。

1.2. AT模式

每个微服务执行SQL并提交，同时生成undo log日志。全部成功统一提交。回滚的话用undolog恢复。

AT模式高可用的模式。AT模式也是Seata官方推荐的模式。也是平时开发中用的最多的一种方式。

TM开启全局的事务，来调用分支事务，让每一个分支事务注册到TC上，各个微服务去执行自己的SQL并提交，RM记录更新前后的快照undo log ,各个分支事务报告自己的业务状态到TC上，再由TM提交或者回滚事务，TC要检查各个分支事务的状态。各个事务都成功了，就提交，通知各个微服务删除undo log日志就行了。如果有事务失败了，就通知回滚，通过undo log日志恢复数据。

1.3. TCC模式

TCC模式也是AP模式，高可用。。前两个是框架自动帮你完成的，代码的耦合度非常低。但是TCC需要用代码手动维护。

Try阶段把资源预留（冻结）

TM开启全局的事务，来调用分支事务，让每一个分支事务注册到TC上，各个微服务去进行资源预留（try）（比如资金冻结），并报告自己的事务状态，TM提交或者回滚事务，TC检查分支事务的状态，各个分支都成功就提交这个事务就行了（这个提交执行的是confirm）（真正的转账了），如果有事务失败就回滚（cancel），就是把之前冻结的资源释放。

2. MQ解决分布式事务

异步的，性能相对高，实时性差。强一致要求不高的话，可以采用。