分布式协议之两阶段提交协议（2PC）和改进三阶段提交协议（3PC）

 

前面我们说过数据库事务性具有ACID4个特性，那么在分布式系统中是怎么保证这4个特性的呢？我们先来看看原子性的实现二阶段提交协议（2PC）.

一、二阶段提交（2PC）

　　分布式系统的一个难点是如何保证架构下多个节点在进行事务性操作的时候保持一致性。为实现这个目的，二阶段提交算法的成立基于以下假设：

1. 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
2. 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

　　第一阶段（投票阶段）：

1. 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
2. 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
3. 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。

　　第二阶段（提交执行阶段）：

　　当协调者节点从所有参与者节点获得的相应消息都为"同意"时：

1. 协调者节点向所有参与者节点发出"正式提交(commit)"的请求。
2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送"完成"消息。
4. 协调者节点受到所有参与者节点反馈的"完成"消息后，完成事务。

　　如果任一参与者节点在第一阶段返回的响应消息为"中止"，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1. 协调者节点向所有参与者节点发出"回滚操作(rollback)"的请求。
2. 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送"回滚完成"消息。
4. 协调者节点受到所有参与者节点反馈的"回滚完成"消息后，取消事务。

　　不管最后结果如何，第二阶段都会结束当前事务。

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

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

　　2、参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。（没有多少容错机制）

　　3、协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。（这个可以依赖后面要讲的Paxos协议实现HA）

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

　　为此，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三阶段提交协议（3PC）。

 

二、三阶段提交协议(3PC)

　　与两阶段提交不同的是，三阶段提交有两个改动点。

　　1、引入超时机制。同时在协调者和参与者中都引入超时机制。

　　2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

 

　　具体流程见下图：

　　

　　具体读者可以参考维基百科和下面的文章，俺就不在赘述了。

　　https://en.wikipedia.org/wiki/Three-phase_commit_protocol

　　ei.cs.vt.edu/~cs5204/fall99/distributedDBMS/sreenu/3pc.html

 

三、画外音

　　2PC协议因为其阻塞的特性，在执行过程中需要锁住其他更新，且容错不够好，所以对其支持的成本较高。分布式系统用2PC协议更多的是处理多个数据分片操作的原子性。而同一个数据分片的多个副本之间的数据一致性则更多的使用Paxos来实现。

　　后面我们就来了解下这个被google在chubby中甚赞（Indeed, all working protocols for asynchronous consensus we have so far encountered have Paxos at their core.）的分布式一致性算法：Paxos！