1阶段提交，2阶段提交，3阶段提交

XA规范

    Open Group定义了一套DTP分布式模型，主要含有：

        AP（应用程序）

        TM（事务管理器）

        RM（资源管理器）   ----  通常指数据库

        CRM（通讯资源管理器）四部分   ---- 消息中间件

     XA则是DTP模型定义TM和RM之前通讯的接口规范。XA接口函数由数据库厂商提供。TM交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 二阶段提交和三阶段提交就是根据这种思想衍生而来。

2PC

    角色：协调者（coordinator），参与者（participants, 或cohort）       

    保证事务在提交时，协调者和参与者处于一致性状态，如果其中有一个参与者出现了故障或者网络问题，不能及时的回应协调者，那么这次事务就宣告失败或者出现阻塞。

准备阶段

        事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交

提交阶段

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

2PC事务提交

2PC事务回滚

    二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：

        1、同步阻塞问题。在事务执行过程中，所有参与节点都是事务阻塞型的。参与者占有公共资源时，其他第三方节点访问公共资源则会处于阻塞。

        2、单点故障。在2PC中由协调者进行协调，一旦协调者发生故障，参与者会阻塞。尤其在第二阶段commit阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

         注：（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

        3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

        4、二阶段无法解决的问题。协调者发出commit消息，并且只有部分参与者收到消息，此时协调者和收到消息的参与者发生宕机。那么即使协调者通过  选举协议  产生了新的协调者，这条事务的状态也是不确定的，集群中不能判断出事务是否被已经提交。

3PC

    相比2PC，3PC引入超时机制，并把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

3PC提交

相对于2PC，3PC主要解决：

单点故障问题

     减少阻塞，因为一旦参与者无法“及时”收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。

     问题：数据一致性问题，例如，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

TCC

    支付宝提出，是一个应用层面的2PC：

         TCC中，每个参与者需要3个操作：Try/Confirm/Cancel，也是2个阶段

阶段1：”资源预留/资源检查“，也就是事务协调者调用所有参与者的Try操作

阶段2：“一起提交”。如果所有的Try成功，一起执行Confirm。否则，所有的执行Cancel.

PAXOS

    由于2PC，3PC都不能保证特殊情况下数据的一致性，由此Paxos收到广泛关注。