分布式事务:XA(2PC、3PC)和TCC

一、XA协议

    XA是X/Open组织 提出的分布式事务处理规范。XA则规范了TM（事务管理器）与RM（资源管理器）之间的通信接口，在TM与多个RM之间形成一个双向通信桥梁，从而在多个数据库资源下保证ACID四个特性。目前知名的数据库，如Oracle, DB2,mysql等，都是实现了XA接口的，都可以作为RM。所以说XA是数据库的分布式事务，强一致性，在整个分布式事务过程中，TM一直把持折数据库的锁，存在长事务风险！XA协议有2PC、3PC。

 1、2PC

阶段一：

阶段二：

 2、3PC

 3、2PC/3PC对比：

1、2PC上来就开启事务锁定资源，阶段一中，如果参与者A、B、C已锁定资源，参与者D因网络中断、宕机或资源不足导致无法锁定资源，虽然阶段二中协调者根据各个参与者反馈的情况最终会发出中止事务，但是在阶段一期间参与者A、B、C的资源都处于锁定阻塞状态，这使得分布式服务性能降低；而3PC相比2PC多了一步——询问检查机制，也就是第一步是先询问各参与者，并没有锁定占用资源，这样即使在参与者D有网络中断、宕机或资源不足的情况下，其他参与者也不会有资源的占用，提高了服务性能。

2、2PC只有协调者超时机制，参与者没有超时机制。阶段二中如果参与者收不到协调者的指令，会一直持有锁定的资源，一直阻塞住直到收到协调者指令，导致无法及时释放资源；而3PC增加了参与者超时机制，阶段一，参与者等待超时则自己失败，阶段二、三则直接自己提交。

二、TCC

TCC是业务层面的分布式事务，最终一致性，柔性事务，不会一直持有资源的锁，但代码侵入性强，需要业务方实现3个接口：Try、Confirm、Cancel
Try阶段：
   完成所有业务检查（一致性），预留业务资源(准隔离性)
Confirm阶段：
   确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。要满足幂等性。
Cancel阶段：
    取消Try阶段预留的业务资源。

三、XA vs TCC

TCC与XA两阶段提交有着异曲同工之妙，下图列出了二者之间的对比 ：

TCC两阶段提交与XA两阶段提交的区别是：

XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。
XA事务中的两阶段提交内部过程是对开发者屏蔽的，开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录，那么就必须等待锁释放。

TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。
TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在。try、confirm/cancel在执行过程中，一般都会开启各自的本地事务，来保证方法内部业务逻辑的ACID特性。