首页 > 代码库 > Two-Phase Commit (两阶段提交)

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

Two-Phase Commit (两阶段提交)