两阶段提交协议

两阶段提交协议是最简单最流行的ACP。在没有故障发生的情况下，它的执行过程如下：

1. 协调者发送一个VOTE-REQ消息给所有的参与者

2.当参与者接收到VOTE-REQ消息后，它会发送一个包含参与者投票结果的消息(YES或NO)给协调者作为响应。如果参与者投的是No，它会决定Abort事务并停止运行

3.协调者收集来自所有参与者的投票信息。如果所有的消息都是YES，同时协调者投的也是Yes，那么协调者就会决定进行Commit，并向所有参与者发送COMMIT消息。否则协调者就会决定进行Abort，并向所有投Yes的参与者发送ABORT消息(那些投No的参与者已经在第2步中决定Abort了)。之后，对于这两种情况协调者都会停止运行

4. 每个投Yes的参与者等待来自协调者的COMMIT或ABORT消息。收到消息后执行相应动作然后停止运行。

2PC的两个阶段是指投票阶段(步骤1和2)和决定阶段(步骤3和4)。参与者的不确定区间始于向协调者发送YES(步骤2)，终于接收到COMMIT或ABORT消息(步骤4)。协调者没有不确定区间，因为只要它投了票结果就确定了，当然它投票时需要知道参与者的投票结果(步骤3)。

很容易可以看出2PC满足条件AC1-AC4。不幸的是，目前为止的描述并不满足AC5。有两个原因，首先在协议的很多点上，进程在继续处理之前必须要等待消息。但是消息可能会由于故障而无法到达。因此，进程可能会无限等待下去。为避免这个问题，需要使用超时机制。当进程的等待因为超时而打断时，进程必须采取特定的动作，称之为超时动作。因此，为满足AC5，必须为协议中进程需要等待消息的地方引入合理的超时动作。

其次，当进程从故障中恢复时，AC5要求进程能够达成与其他进程可能已经达成的决定相一致的决定(可能还必须要等待某些其他故障修复之后才能达成这样的决定)。因此，进程还必须要将某些信息存入可靠性存储中，比如DTlog中。为满足AC5，我们还必须要说明需要将哪些信息存入DT log以及如何在恢复时使用它们。下面我们分别来考虑这两个问题。