兩階段提交協議

兩階段提交協議是最簡單最流行的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以及如何在恢復時使用它們。下面我們分別來考慮這兩個問題。

兩階段提交協議

兩階段提交協議

兩階段提交協議

兩階段提交協議

相關推薦