XA

两阶段提交

TC：协调者，用来协调全局事务，

RM：资源，也就是数据库，用来处理本地子事务

TM：事务管理者，也就是发起分布式事务的调用方

1、TM发起发起全局事务，向TC注册全局事务，分配对应的全局事务ID

2、RM先执行对应的子事务，但是不提交，向TC注册子事务，并且报告对应的状态

3、如果所有RM的子事务的状态都正确，进入全局事务提交阶段。TC会向RM发送提交信息。RM收到信息后，提交本地事务

4、如果有任何一个向TC发送了错误信息，TC会向所有的RM发送回滚命令

缺点：
在全局事务提交之前，RM事务都处于未提交状态，一直占用资源，导致性能下降

AT

两阶段提交

AT是XA的改进版，引入了undolog表，undolog通过全局事务ID和本地事务ID来表示一个事务，存储了事务修改前beforeimage和修改后的记录afterimage的值。这样的话，本地子事务可以先于全局事务提交。如果发生错误，就通过undolog里面的数据进行回滚，这样就提高了性能。

虽然本地子事务先于全局事务提交，但是AT在TC端维护了全局锁来保证分布式事务的隔离性，通过db + table + id + shade（分片） 来表示一行记录，保证同时只有一个分布式事务来更改数据，但是这防止不了本地单机事务更改数据。

只有当当前值和afterimage一样的时候，才能回滚，否则说明在全局事务期间有本地事务更改了该值（也就是其他事务并没有通过分布式事务提交，而是本地单机事务），这个时候需要人工介入。

TCC

两阶段提交

tcc的全称为try confirm cancel，每个数据库对应的数据服务需要提供try confirm 和cancel三个接口。

try：预留资源操作，来检查是否进行对应的操作，比如转账系统中，先冻结对应的金额，并不扣费。这需要在数据库中额外加入一个字段来表示冻结状态

confirm：真正的更改数据操作

cancel： 将预留资源释放，try的反操作。

TCC也需要TC来协调分布式事务

TC首先向所有事务参与者发起try请求，如果某个事务参与者返回No，就像所有事务参与者发送cancel命令。

如果所有事务参与者都返回Yes，TC会就调用所有参与者的confirm方法。

缺点：侵入业务代码
好处：性能好