两阶段提交协议（two phase commit protocol，2PC）

两阶段提交协议（two phase commit protocol，2PC）

     两阶段提交协议可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某些情况下它还需要人为的参与才能解决问题。参与者为了能够从故障中恢复，它们都使用日志来记录协议的状态，虽然使用日志降低了性能但是节点能够从故障中恢复。

在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写前日志（write-ahead log）并持久性存储，即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节点都可以互相通信。

当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务能够成功完成回复同意提交事务或者回滚事务。

顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

阶段2：提交阶段（commit phase）

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

 

注意  两阶段提交协议与两阶段锁协议不同，两阶段锁协议为一致性控制协议。

 

该协议的执行过程可以通过下图X-X来描述：

               （a）成功                                   （b）失败

图X-X：两阶段提交

 

两阶段提交协议最大的劣势是其通过阻塞完成的协议，在节点等待消息的时候处于阻塞状态，节点中其他进程则需要等待阻塞进程释放资源才能使用。如果协调器发生了故障，那么参与者将无法完成事务则一直等待下去。以下情况可能会导致节点发生永久阻塞：

如果参与者发送同意提交消息给协调者，进程将阻塞直至收到协调器的提交或回滚的消息。如果协调器发生永久故障，参与者将一直等待，这里可以采用备份的协调器，所有参与者将回复发给备份协调器，由它承担协调器的功能。

如果协调器发送“请求提交”消息给参与者，它将被阻塞直到所有参与者回复了，如果某个参与者发生永久故障，那么协调器也不会一直阻塞，因为协调器在某一时间内还未收到某参与者的消息，那么它将通知其他参与者回滚事务。

同时两阶段提交协议没有容错机制，一个节点发生故障整个事务都要回滚，代价比较大。

下面我们通过一个例子来说明两阶段提交协议的工作过程：

A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用2PC算法解决该问题的过程如下：

首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。

阶段1：

A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。

B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因，D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。

阶段2：

此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。

此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。

 

通过该例子可以发现，2PC协议存在明显的问题。假如D一直不能回复邮件，那么A、B和C将不得不处于一直等待的状态。并且B和C所持有的资源，即下周三不能安排其它活动，一直不能释放。其它等待该资源释放的活动也将不得不处于等待状态。

基于此，后来有人提出了三阶段提交协议，在其中引入超时的机制，将阶段1分解为两个阶段：在超时发生以前，系统处于不确定阶段；在超市发生以后，系统则转入确定阶段。

2PC协议包含协调者和参与者，并且二者都有发生问题的可能性。假如协调者发生问题，我们可以选出另一个协调者来提交事务。例如，班长组织活动，如果班长生病了，我们可以请副班长来组织。如果协调者出问题，那么事务将不会取消。例如，班级活动希望每个人都能去，假如有一位同学不能去了，那么直接取消活动即可。或者，如果大多数人去的话那么活动如期举行（2PC变种）。为了能够更好地解决实际的问题，2PC协议存在很多的变种，例如：树形2PC协议（或称递归2PC协议）、动态2阶段提交协议（D2PC）等。

下面列举一个分布式系统中实际使用2PC的例子：

  两阶段提交算法在分布式系统结合，可实现单用户对文件（对象）多个副本的修改，多副本数据的同步。其结合的原理如下：

1. 客户端（协调者）向所有的数据副本的存储主机（参与者）发送：修改具体的文件名、偏移量、数据和长度信息，请求修改数据，该消息是1阶段的请求消息。
2. 存储主机接收到请求后，备份修改前的数据以备回滚，修改文件数据后，向客户端回应修改成功的消息。如果存储主机由于某些原因（磁盘损坏、空间不足等）不能修改数据，回应修改失败的消息。
3. 客户端接收发送出去的每一个消息回应，如果存储主机全部回应都修改成功，向每存储主机发送确认修改的提交消息；如果存在存储主机回应修改失败，或者超时未回应，客户端向所有存储主机发送取消修改的提交消息。该消息是2阶段的提交消息。
4. 存储主机接收到客户端的提交消息，如果是确认修改，则直接回应该提交OK消息；如果是取消修改，则将修改数据还原为修改前，然后回应取消修改OK的消息。
5. 客户端接收全部存储主机的回应，整个操作成功。

  在该过程中可能存在通信失败，例如网络中断、主机宕机等诸多的原因，对于未在算法中定义的其它异常，都认为是提交失败，都需要回滚，这是该算法基于确定的通信回复实现的，在参与者的确定回复（无论是回复失败还是回复成功）之上执行逻辑处理，符合确定性的条件当然能够获得确定性的结果哲学原理。 
  缺点：单个A是个严重问题：没有热备机制，A节点宕机了或者链接它的网络坏了会阻塞该事务；吞吐量不行，没有充分发动更多A的力量，一旦某个A第一阶段投了赞成票就得在它上面加独占锁，其他事务不得接入，直到当前事务提交or回滚。

参考文献：

维基百科：http://en.wikipedia.org/wiki/Two-phase_commit_protocol

两阶段提交协议与三阶段提交协议之比较：http://my.oschina.net/digerl/blog/34139

NoSQL数据库笔谈：http://sebug.net/paper/databases/nosql/Nosql.html#_08464202471077442_91161458194