Two-Phase Commit (兩階段交易認可)

標籤：blog   http   os   使用   io   ar   2014   art   div   

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會因此決定進行ABORT3. 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/70971767201311810939564http://research.microsoft.com/en-us/people/philbe/chapter7.pdf

Two-Phase Commit (兩階段交易認可)