兩階段與三階段提交協議

首先了解一下為什麼要使用多階段提交協議這個東西。

在分布式系統中，我們會存在乙個方法對多個庫進行插入或更新。但是每個節點只能知曉自己的操作是成功或失敗，卻無法知道其他節點的成功和失敗。這樣的話就會導致資料的不一致性。當乙個事務跨越了多個節點時，為了保持資料的一致性，所以就引進了兩階段提交協議這個東西。

所謂兩階段提交協議：第一階段：準備階段（投票階段）

第二階段：提交階段（執行階段）

在兩階段提交協議中，系統一般包含兩類節點。一、協調者。二、參與者

兩個階段的執行步驟：

協調者向所有的參與者請求能不能處理事務，參與者會告知協調者能與不能。如果能就把協調告知的事務執行，但不提交。不能就直接返回。

協調者會獲取到所有參與者返回的結果。當所有的參與者同意提交事務，協調者才會通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。

兩階段提交的缺點

同步阻塞的問題。

在執行過程中，所有參與者節點都是事務阻塞型的。當參與者占有公共資源時，其他的節點訪問公共資源時不得不處於阻塞狀態，導致系統處理效率下降。

2.單點故障。

當執行第二階段時，協調者發生故障，參與者會一直阻塞下去。

3.資料不一致。在執行第二階段時，當協調者想參與者傳送提交的請求之後，發生了區域性網路異常或者在發生commit請求過程中協調者發生故障，會導致只有一部分參與者接收到了commit請求。

兩階段提交無法解決的問題

當協調者出錯，同時參與者也出錯時，兩階段無法保證事務執行的完整性。考慮到協調者在發出commit訊息之後宕機，而唯一接收到這條訊息的參與者也同時宕機。那麼即使協調者通過選舉協議產生了新的協調者，這條事務額狀態也不是確定的，沒人知道事務是否被提交。

三階段提交協議：

執行步驟

cancommit階段

事務詢問，協調者向參與者傳送precommit請求。詢問是否可以執行事務。

響應反饋參與者接到cancommit請求。

precommit階段

協調者根據參與者的返回來決定是否繼續事務的precommit操作。但是會出現兩種情況

協調者從所有參與者獲得反饋都是yes，那麼事務會繼續執行

如果有任何乙個參與者向協調者傳送了no響應，或者等待超時，協調者沒有接收到參與者的響應那麼事務中斷。

docommit階段

執行提交

1.傳送提交請求協調接收到參與者傳送的ack響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送docommit請求。

2.事務提交參與者接收到docommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。

3.響應反饋事務提交完之後，向協調者傳送ack響應。

4.完成事務協調者接收到所有參與者的ack響應之後，完成事務。

事務中斷，協調者沒有接收到參與者傳送的ack響應（可能是接受者傳送的不是ack響應，也可能響應超時），那麼就會執行中斷事務。

1.傳送中斷請求協調者向所有參與者傳送abort請求

2.事務回滾參與者接收到abort請求之後，利用其在階段二記錄的undo資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。

3.反饋結果參與者完成事務回滾之後，向協調者傳送ack訊息

4.中斷事務協調者接收到參與者反饋的ack訊息之後，執行事務的中斷。

三階段與二階段的不同點在於。

對於協調者和參與者都設定了超時機制（2階段中只有協調者有）。協調者如果在一定時間內沒有收到參與者的訊息則預設失敗，參與者無法及時收到協調者的資訊，他會預設執行commit,不會一直持有事務。

解決了單點故障，並減少了阻塞。但是也會帶來資料不一致的問題。如果網路出錯，協調者傳送的請求沒有及時被參與者收到，那麼參與者在等待超時之後執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在資料不一致的情況。