Two-Phase Commit (两阶段提交)

1. 流程

1) Coordinator (协调者) 广播 VOTE-REQ 给全部 Participant (参与者)

2) Coordinator 等待 Participant 的结果

3) Participant 回复 YES or NO 给 Coordinator

4) Coordinator 收集全部结果后, 广播 COMMIT or ABORT 给全部 Participant

其中, 当 Participant 处于 状态 3 与 状态 4 之间的时候(已经发送 YES 并等待 Coordinator 的回复)称之为不肯定状态, 这个状态处于阻塞状态

 

2. 超时协议

Participant 与 Coordinator 可能会处于没法通讯的状态, 这时候能够有不一样的处理策略

1) Termination Protocol

在与协调者的通讯恢复以前p始终保持阻塞。以后，协调者通知p对应的决定结果。协调者确定支持这样作，由于它没有不肯定区间。该terminaion protocol知足AC5，由于若是全部的故障都修复了的话，p就能与协调者通讯，而后就能达到决定状态。

 

这种简单的terminaion protocol缺点在于，p可能要经历没必要要的阻塞。好比，假设如今有两个参与者p和q。协调者先给q发送了一个COMMIT或ABORT消息，可是在发送给p以前发生了故障。所以，尽管p是不肯定的，可是q不是。若是p能够与q进行通讯，那么它就能够从q那得知最终的决定结果。并不须要一直等待着协调者的恢复。

2) Cooperative Termination Protocol

参与者p若是在不肯定区间超时，它会发送一个DECISION-REQ消息给全部其余进程，设为q，问下q是否知道决定结果或者可否单方面地作出决定。在这个场景中，p是initiator，q是responder。有以下三种状况：

1. q已经决定进行Commit(或Abort)：q简单地发送一个COMMIT(或ABORT)消息给p，而后p进行相应动做

2. q还未进行投票：q能够单方面地决定进行Abort。而后它发送ABORT消息给p，p会所以决定进行ABORT

3. q已经投了Yes可是还未作决定：q也是处于不肯定状态，所以没法帮助p达成决定。

 

对于该协议来讲，若是p能够同某个进程q通讯而且上述1或2成立，那么p就能够不经阻塞地达成决定。另外一方面，若是p通讯的全部进程都是3成立，那么p就会被阻塞。那么p将会一直阻塞，直到故障修复的出现了某个进程q知足条件1或2为止。

 

3. 故障

Coordinator 和 Participant 有可能会发生故障, 故障恢复后, 须要根据发生故障时的状态来决定, 因此须要将各个状态写入 DT log

* 若是DT log包含一个start-2PC记录，那么说明S就是协调者所在节点。若是它还有commit(或abort)记录，那么说明在发生故障前协调者已经作出了决定。若是这两种记录(commit或abort)都没有找到，那么协调者能够经过向DT log中插入一条abort记录来单方面地决定进行Abort。这样能够工做的关键在于，协调者是先将commit记录写入DT log，而后再发送COMMIT消息的(上面的第3点)。

* 若是DT log中没有start-2PC记录，那么S就是参与者节点。那么有以下三种可能：

* DT log中包含一个commit(或abort)记录。那么说明在发生故障以前，参与者已经达成了决定。

* DT log中没有yes记录。那么要么是参与者是在投票前发生的故障，要么投的是No(可是在发生故障前尚未完成abort记录的写入)。(这也是为什么yes记录必需要在发送YES消息前写入日志的缘由；参考上面的第2点。)所以，它能够单方面地经过向DT log中写入一条abort记录决定进行Abort。

* DT log中包含了yes记录，可是没有commit(或abort)记录。那么说明参与者是在不肯定区间内发生的故障。它能够经过使用terminaion protocol来达成决定。回想一下，yes记录中包含了协调者名称以及全部的参与者，这正是terminaion protocol所须要的。

 

整理自 

http://duanple.blog.163.com/blog/static/70971767201311810939564

http://research.microsoft.com/en-us/people/philbe/chapter7.pdf