一致性協議之三階段提交

原文地址：《一致性協議之三階段提交》

在上一篇文章《一致性協議之二階段提交》中介紹了二階段提交協議的設計和原理，也瞭解了在實際執行過程中可能存在的一些問題，因此研究者在二階段提交協議的基礎上進行了改進，提出了三階段提交協議。

協議說明

3PC，是Three-Phase Commit的縮寫，即三階段提交，是2PC的改進版，將二階段提交協議的“提交事務請求”過程分為二步，形成了CanCommit、PreCommit和doCommit三個階段組成的事務下得協議，協議設計如下圖：

下面我們來看一下協議的詳細說明。

階段一：CanCommit

1. 事務詢問

   協調者向所有參與者傳送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作，並進入等待各參與者響應狀態。

2. 參與者響應

   參與者接收到協調者的canCommit請求後，如果認為可以順利執行事務則反饋Yes響應，並進入預備狀態，否則反饋No響應。

階段二：PreCommit

在階段二中，協調者會根據各參與者的響應來決定是否進行事務的PreCommit操作，階段二中會包含以下兩種可能。

執行事務預提交

如果協調者從所有參與者獲得的反饋都是Yes響應，那麼會執行預提交。

1. 傳送預提交請求

   協調者向所有參與者傳送preCommit請求，並進入Prepared階段。

2. 事務預提交

   參與者收到preCommit請求後，會執行事務操作，並將Undo和Redo資訊記錄到事務日誌中。

3. 向協調者反饋事務執行響應

   如果參與者成功執行了事務操作，反饋給協調者Ack響應，並進入等待最終指令狀態中，最終指令包括提交（commit）或終止（abort）。

中斷事務

如果任何一個參與者反饋了No響應，或在協調者等待所有參與者反饋時發生了超時，那麼就會中斷事務。

1. 傳送中斷請求

   協調者向所有參與者傳送abort請求。

2. 中斷事務

   參與者如果接收到了協調者的abort請求，或者在等待協調者請求過程中出現超時，參與者都會中斷事務。

階段三：doCommit

該階段會對事務進行真正的提交，也會存在下面兩種情況。

執行提交

如果在第二階段協調者接收到了所有參與者的Ack響應，那麼協調者就從預提交狀態轉換到提交狀態，並向所有參與者發出doCommit請求。

1. 傳送提交請求

   向所有參與者傳送commit請求。

2. 事務提交

   參與者接收到doCommit請求後，會正式執行事務提交操作，並在提交成功後釋放事務執行期間佔用的事務資源。向協調者傳送Ack訊息。

3. 完成事務

   協調者接收到所有參與者反饋的Ack訊息後，完成事務。

中斷事務

如果在階段二中，協調者接收到了參與者的No響應，或者在等待參與者響應時發生了超時，就會中斷事務。

1. 傳送中斷請求

   協調者向所有參與者傳送abort請求。

2. 事務回滾

   參與者接收到abort請求後，會利用階段二中記錄的Undo資訊來執行事務回滾操作，並在回滾成功後釋放所有事務執行期間佔用的事務資源。向協調者傳送Ack訊息。

3. 中斷事務

   協調者接收到所有參與者反饋的Ack訊息後，中斷事務。

這裡有一點需要注意，當進入階段三後，如果協調者出現問題或協調者與參與者通訊出現問題。這兩種情況都會導致參與者無法及時收到協調者的commit或abort請求，針對這種問題參與者會在等待超時後自動進行事務的提交。

三階段提交協議的設計描述比較多，為了便於理解，將上述的描述內容整理了一個表格和流程圖可以方便大家的理解。

優缺點

• 優點：相比於二階段提交協議，三階段提交協議最大的優點就是降低了參與者的阻塞範圍，並且能夠在出現單點故障後繼續達成一致。

• 缺點：資料的不一致，在階段三中，如果參與者接收到了preCommit訊息後，出現了不能與協調者正常通訊的問題，在這種情況下，參與者依然會進行事務的提交，這就出現了資料的不一致性。