二阶段提交与三阶段提交

前面几篇博客中提到了CAP原理，以及CAP的几种组合，比如符合AP的有Gossip协议；符合CP的有Paxos协议；符合CA的有二阶段提交(2PC). 这篇文章就来介绍下二阶段提交和有所改进的三阶段提交。

二阶段提交(2PC)

为了使分布式系统架构下所有节点在进行事务提交时保持一致性而设计的一种算法。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果，并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈决定各参与者是否要提交操作还是中止操作。

第一阶段：准备阶段
第二阶段：提交阶段

第一阶段：准备阶段

事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，但不提交，达到一种“万事俱备，只欠东风”的状态。

具体分为3个步骤：
1.1 协调者询问所有参与者是否可以执行提交操作(vote)，并等待各参与者的响应。
1.2 参与者执行事务操作，但没有提交（即没有commit）
1.3 各参与者响应协调者的询问。如果参与者的事务操作执行成功，则返回”同意”；如果参与者的事务操作执行失败，则返回”中止”。

第二阶段：提交阶段

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

两阶段提交(2PC)的几个缺点

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

2. 单点故障
   由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3. 数据不一致
   在阶段二，当协调者向参与者发送commit请求之后，发生了网络异常，这将导致只有部分参与者收到了commit请求。这部分参与者接到commit请求之后就会执行commit操作，但是其他未接到commit请求的参与者则无法执行事务提交，于是整个分布式系统便出现了数据不一致的问题。

4. 二阶段无法解决的问题
   协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

三阶段提交

由于二阶段提交存在以上诸多问题，所以研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。

三阶段提交有2个改动：

1. 在协调者和参与者中都引入了超时机制。
2. 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

三阶段提交分为三个阶段： CanCommit、PreCommit、DoCommit

1. CanCommit阶段

协调者向参与者发送commit请求，参与者如果可以提交就返回Yes，否则返回No.

1. 事务询问
   协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，并进入等待

2. 响应反馈
   参与者接到CanCommit请求之后，如果认为可以顺利执行事务，则返回Yes，并进入预备状态；否则反馈No

2. PreCommit阶段

协调者根据参与者的响应来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下2种可能： 事务预执行 或 中断事务

2.1 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1. 发送预提交请求
   协调者向参与者发送PreCommit请求，并进入Prepared阶段。

2. 事务预执行
   参与者接收到PreCommit请求后，会执行事务操作

3. 响应反馈
   如果参与者成功执行了事务操作，则返回ACK响应，同时开始等待最终指令。

2.2 假如有任何一个参与者向协调者发送了No响应或等待超时,那么就执行事务的中断

1. 发送中断请求
   协调者向所有参与者发送abort请求。

2. 中断事务
   参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

3. DoCommit阶段

该阶段进行真正的事务提交，也可以分为以下两种情况: 执行提交 或 中断事务

3.1 执行提交

1. 发送提交请求
   协调者接收到参与者发送的ACK响应，那么它将从预提交状态进入到提交状态。并向所有参与者发送DoCommit请求。

2. 事务提交
   参与者接收到DoCommit请求之后，执行正式的事务提交；并在完成事务提交之后释放所有事务资源。

3. 响应反馈
   事务提交完之后，向协调者发送Ack响应。

4. 完成事务
   协调者接收到所有参与者的Ack响应之后，完成事务。

3.2 中断事务
协调者没有接收到参与者发送的ACK响应（不是ACK或超时），那么就执行中断事务。

1.发送中断请求
协调者向所有参与者发送abort请求

2.事务回滚
参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3.反馈结果
参与者完成事务回滚之后，向协调者发送ACK消息

4.中断事务
协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

在DoCommit阶段，如果参与者无法及时接收到来自协调者的DoCommit或者abort请求，则在等待超时之后，会继续进行事务的提交。

2PC与3PC的区别

相对于2PC，3PC主要解决单点故障问题，并减少阻塞（一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态）。
但是3PC也有数据一致性问题: 比如，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致了。

（完）