分布式事务两阶段提交(XA)

两阶段提交也不能100%保证数据一致性，但是可以很大程度保证。具体见下文。

数据库支持的2PC【2 phase commit 二阶提交】，又叫做XA Transactions。
MySQL 从5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。
其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段

1.准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。(关于每一个参与者在准备阶段具体做了什么目前我还没有参考到确切的资料，但是有一点非常确定：参与者在准备阶段完成了几乎所有正式提交的动作，有的材料上说是进行了“试探性的提交”，只保留了最后一步耗时非常短暂的正式提交操作给第二阶段执行。)

2.提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。（唯一理论上两阶段提交出现问题的情况是当协调者发出提交指令后当机并出现磁盘故障等永久性错误，导致事务不可追踪和恢复）

 

 XA 协议比较简单，而且一旦商业数据库实现了XA 协议，使用分布式事务的成本也比较
低。
 XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景
 XA 目前在商业数据库支持的比较理想，在mysql 数据库中支持的不太理想，mysql 的
XA 实现，没有记录prepare 阶段日志，主备切换回导致主库与备库数据不一致。
 许多nosql 也没有支持XA，这让XA 的应用场景变得非常狭隘。
 也有3PC，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间
未收到回应则做出相应处理）