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