文章目錄

• • 1. 簡介
  • 2. three phase commit協議概覽
  • 3. 協議介紹
  • • 1. 協議假設
    • 2. 協議詳情
    • • 1. 階段一
      • 2. 階段二
      • 3. 階段三
  • 4. 一些定義
  • 5. 導致block的情況

1. 簡介

??先簡單介紹一下，這篇文章也是根據一些英文文檔翻譯和整理得來的，但是真正的3pc只是在一個論文中有提及，并沒有做特別嚴格的論證和描述（就像是為了說明問題A，拿了一個問題B舉例子一樣），我這里的分析不能保證準確，而且3pc也缺乏使用的場景。下面來一起簡單學習一下吧。

容錯計算機系統可防止中斷提供給用戶的服務。可以通過兩種方式將系統設計為容錯的。實現它們的技術如下：

投票協議(Voting Protocols)：用于設計掩蓋故障的系統，盡管發生故障，這些系統仍將繼續執行其指定的功能。

提交協議(Commit Protocols)：它們用于設計在出現故障時表現出明確定義的行為的系統。這些系統在故障期間可能會執行或可能不會執行指定的功能，但是它們可能執行有助于恢復的操作。

有兩種commit類型的協議

Two-Phase Commit protocol - a blocking protocol

Three-Phase Commit protocol - a non-blocking protocol

這里來探討一下Three-Phase Commit protocol 也就是常說的3pc協議。

2. three phase commit協議概覽

??雖然兩階段提交協議保證了全局原子性，但它的最大缺點是它是阻塞協議。每當coordinator發生故障時，cohort站點需要等待其恢復。在這個過程中這些站點可能會鎖定資源,這些鎖資源對于其他線程是不可訪問的。同時，在消息丟失的情況下，兩階段協議將導致發送更多消息。

如果要求事務操作必須能夠抵抗站點故障,那么系統必須滿足以下條件

站點故障時，提交協議不能阻塞

發生失敗的站點，一旦恢復，就事務操作結果都必須得出和其他站點相同的結論

運行中的節點應通過檢查當地狀況來達成事務操作結果(不需要一直等待來自coordinator的指令)，而且該決定必須與其他運行的節點的最終結果一致（這個主要是指在阻塞超時的情況下）

3. 協議介紹

1. 協議假設

每個site都使用write-ahead-log協議來交互（先記錄日志進行持久化，然后再操作）

在事務執行的過程中最多有一個site可以fail

不能發生網絡分區的情況（partition）

這里感覺3pc需要繼承2pc的假設，同時又增加了不能出現網絡分區的情況（network partition）

2. 協議詳情

協議分為3個階段

1. 階段一

事務的coordinator在其日志文件中寫入BEGIN_COMMIT消息，并將PREPARE消息發送到所有參與cohorts并等待。

收到此消息后，如果cohorts準備提交，則cohorts的事務管理器（TM）將READY寫入其日志中，并將VOTE_COMMIT發送給TC。

如果任何cohorts尚未準備好提交，它將在其日志中寫入ABORT并以VOTE_ABORT響應TC。

2. 階段二

如果coordinator 從所有參與cohorts接收到VOTE_COMMIT，則它將PREPARE_TO_COMMIT寫入其日志中，并將PREPARE_TO_COMMIT消息發送到所有參與cohorts。

另一方面，如果TC收到任何一個VOTE_ABORT消息，它將在其日志中寫入ABORT并將GLOBAL_ABORT發送到所有參與cohorts，并且還將END_OF_TRANSACTION消息寫入其日志中。

如果這個時候因為某個cohorts宕機導致coordinator在階段一等待超時，那么會發送global abort到其他的cohorts,宕機的節點發現自己沒有收到PREPARE_TO_COMMIT則也可以清除之前產生的事務

參與cohorts的TM在收到消息PREPARE_TO_COMMIT時，將PREPARE_TO_COMMIT寫入其日志中，并以READY_TO_COMMIT消息響應給TC。

如果cohorts接收到GLOBAL_ABORT消息，則cohorts的TM在其日志中寫入ABORT并確認中止。同樣，他們在本地中止該特定事務。

如果coordinator在發送Prepare消息之前失敗，coordinator將在恢復時中止事務。cohort等待準備消息超時，并且也中止事務。

假如coordinator在Prepare消息發出去一部分之后失敗，那不就完了么😰，理論上發送給所有的cohort并不是一個原子操作，但是這個是不是可以通過cohorts之間的通信來解決，所以最終也是提交。cohorts只有兩個節點呢(因為這里只允許一個節點失效，所以不影響，這個是我個人增加的一種情況)

3. 階段三

如果所有響應均為READY_TO_COMMIT，則coordinator將COMMIT寫入其日志中，并將GLOBAL_COMMIT消息發送到所有參與cohorts的TM。

然后，這些cohorts的TM在其日志中寫入COMMIT并將確認發送給TC。然后，TC在其日志中寫入END_OF_TRANSACTION。

如果coordinator在發送commit消息之前失敗，則它在恢復時提交事務。這時cohort等待Commit消息超時，也會提交事務。

但是，如果cohorts在向coordinator的PREPARE_TO_COMMIT消息發送確認消息之前失敗，則coordinator等待超時,這個時候coordinator將中止事務并將“中止”消息發送給所有同類cohort。失敗的cohort在恢復后將根據來自狀態wi的失敗事務中止事務。

也就是在commit階段coordinator宕機導致的超時和cohort宕機導致的超時的處理方式是不一樣的。

4. 一些定義

同步協議
如果一個站點在協議執行過程中從未通過一個以上的狀態轉移來引導另一個站點，則該協議在一個狀態轉換內被稱為同步。

5. 導致block的情況

??讓我們看看導致兩階段提交協議塊的條件。考慮一個簡單的情況，其中只有一個站點可以運行，而所有其他站點都已失敗。該站點必須僅根據其本地狀態進行。讓我們表示此時的站點狀態。如果可能的狀態同時包含提交和中止狀態，則該站點無法決定中止事務，因為其他人可能處于提交狀態。另一方面，該站點無法決定提交事務，因為其他站點可能處于中止狀態。換句話說，該站點必須阻塞，直到所有失敗的站點恢復為止。
如何避免block
為了使兩階段提交協議成為非阻塞協議，可以通過引入緩沖區狀態來完成。

這個三階段提交協議，看了很多文章，感覺說的都不夠嚴謹，當然我這里討論的也不夠全面，因為原作者的論述也不夠清晰，實際上的使用和實現更少（比2pc更少），真正的分布式一致性的協議鼻祖還是paxos，大部分現在流行的raft,pacificA等都是在這個基礎上演化的。

參考一
參考二
參考三

總結

以上是生活随笔為你收集整理的3pc_three phase commit protocol协议理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。