分佈式理論之2PC協議(2階段提交協議)

系列文章 -> 分佈式理論

1. 分佈式理論之CAP定理（布魯爾定理）
2. 分佈式理論之BASE理論
3. 分佈式理論之2PC協議(2階段提交協議)

2PC是什麼

同前文，2PC也是縮寫，即Two-phase Commit，即二階段提交

目的

用以保證在分佈式事務中，要麼全部參與進程都提交事務，要麼都取消事務，即實現ACID的原子性（A）。在數據一致中，它的含義是：要麼全部副本（備份數據）同時修改某個數值，要麼都不更改，以此來保證數據的強一致性。

知識預備 - 預寫式日誌(Write-Ahead logging(WAL))

在計算機科學中，預寫式日誌（Write-ahead logging，縮寫 WAL）是關係數據庫系統中用於提供原子性和持久性（ACID屬性中的兩個）的一系列技術

二階段提交算法成立的基本假設

• 分佈式系統中,存在一個節點做爲協調者,其餘節點做爲參與者
• 全部節點都採用預寫式日誌,且日誌被寫入後即被保持在可靠的存儲設備上,即便節點損壞也不會致使日誌數據消失
• 全部節點不會永久性損壞,即便損壞後仍然能夠恢復,且節點之間能夠互相通訊

基本假設是有風險的

• 全部節點能夠互相通訊,這個通常不是什麼大問題,一般能夠從新路由網絡通訊
• 全部節點不會永久損壞,這個問題很大,好比服務器炸了

二階段提交具體操做

提交請求階段(投票階段)

第一階段也被稱做投票階段，即各參與者投票是否要繼續接下來的提交操做

1. 協調者節點向全部參與者節點詢問是否能夠執行提交操做（QUERY TO COMMIT），並開始等待各參與者節點的響應。
2. 參與者節點執行詢問發起爲止的全部事務操做，並將undo信息和redo信息寫入日誌(預寫式日誌)。
3. 各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功，則它返回一個"贊成"(YES)消息；若是參與者節點的事務操做實際執行失敗，則它返回一個"停止"(NO)消息

提交執行階段(執行階段)

第二階段也被稱做完成階段，由於不管結果怎樣，協調者都必須在此階段結束當前事務。

成功

當協調者節點從全部參與者節點得到的相應消息都爲"贊成"時：

1. 協調者節點向全部參與者節點發出"正式提交"(COMMIT)的請求。
2. 參與者節點正式完成操做，並釋放在整個事務期間內佔用的資源。
3. 參與者節點向協調者節點發送"完成"(ACKNOWLEDGMENT)消息。
4. 協調者節點收到全部參與者節點反饋的"完成"消息後，完成事務。

失敗

若是任一參與者節點在第一階段返回的響應消息爲"終止"，或者 協調者節點在第一階段的詢問超時以前沒法獲取全部參與者節點的響應消息時：

1. 協調者節點向全部參與者節點發出"回滾操做"(ROLLBACK)的請求。
2. 參與者節點利用以前寫入的undo信息執行回滾，並釋放在整個事務期間內佔用的資源。
3. 參與者節點向協調者節點發送"回滾完成"(ACKNOWLEDGMENT)消息。
4. 協調者節點收到全部參與者節點反饋的"回滾完成"消息後，取消事務。

2PC是否能夠在任何狀況下均可以解決一致性問題

咱們僅從理論上分析各類意外，由於實際的網絡生產中，各類狀況都有可能發生

協調者不一樣階段宕機的不一樣現象

狀況	分析及解決方案
協調者掛了，參與者沒掛	只要找一個協調者的替代者，新的協調者詢問全部參與者它們最後那條事務的執行狀況，新協調者就知道該作什麼樣的操做了。這種狀況不會致使數據不一致
參與者掛了（沒法恢復），協調者沒掛	若是掛了以後沒有恢復，則不會致使數據不一致
參與者掛了（後來恢復），協調者沒掛	恢復後參與者若是發現有未執行完的事務操做，直接取消，而後再詢問協調者我應該怎麼作，協調者就會比對本身的事務執行記錄和該參與者的事務執行記錄，告訴他應該怎麼作來保持數據的一致
參與者掛了，協調者也掛了	須要再細分爲幾種類型來討論，以下

參與者掛了，協調者也掛了的狀況

• 協調者和參與者在投票階段掛了

  • 因爲這時尚未執行提交操做，新選出來的協調者能夠詢問各個參與者的狀況，再決定是進行提交仍是回滾。由於沒有提交，不會致使數據不一致

• 協調者和參與者在執行階段掛了，可是掛的這個參與者在掛以前尚未作相關操做

  1. 選出新的協調

  2. 協調者詢問全部參與者的狀況。

     • 有參與者執行了roolback操做或投票階段返回的信息是No，那麼協調者指導參與者執行roolback操做。
     • 若是存在參與者執行了commit操做且其他參與者沒有abort，那麼協調者就指導參與者執行commit操做。由於掛掉的機器並無作 commit 或者 roolback 操做，而沒有掛掉的機器們和新的協調者又執行了一樣的操做，那麼這種狀況不會致使數據不一致現象

• 協調者和參與者在第二階段掛了，掛的這個參與者在掛以前已經執行了操做

  • 掛的參與者沒有恢復：這種狀況下，就變成和上述狀況一致了，由於即便執行了，永遠沒有恢復就和沒有執行時同樣的。因此此時不會致使數據不一致現象

  • 掛掉的參與者恢復了：因爲參與者在掛以前執行了操做，此時是沒有人知道它執行了什麼操做，它已經執行完了以前的事務

    • 若是它執行的是commit：此時這個掛掉且恢復的參與者和其它參與者保持一致了
    • 若是它執行的是roolback：此時會致使數據的不一致，雖然這個時候能夠再經過手段讓他和協調者通訊，再想辦法把數據變成一致的，可是，這段時間內他的數據狀態已是不一致了

小結

2PC協議中，若是出現協調者和參與者都掛了的狀況，有可能致使數據不一致。爲了解決這個問題，衍生出了3PC，這是後話。

2PC 優缺點和解決方案

優缺點

• 優勢：原理簡潔清晰、實現方便；
• 缺點：同步阻塞、單點問題、某些狀況可能致使數據不一致。

解決方案

關於這幾個缺點，在實際應用中，都是對2PC 作了相應的改造：

• 同步阻塞：2PC 有幾個過程（好比協調者等待全部參與者表決的過程當中）都是同步阻塞的，在實際的應用中，這可能會致使長阻塞問題，這個問題是經過超時判斷機制來解決的，但並不能徹底解決同步阻塞問題；
• 協調者單點問題：實際生產應用中，協調者都會有相應的備選節點；
• 數據不一致：在提交階段，協調者和參與者都出現掛掉的狀況下，是有可能致使數據不一致的，衍生出了3PC。

總結

在分佈式系統中，每一個節點能夠知道本身的操做是成功仍是失敗，但沒法知道其餘節點的操做狀態，爲了在跨多個節點的事務中保持事務的ACID特性，咱們會引入一個「協調者」的組件來統一掌握全部節點（參與者）的操做狀態，並指示這些節點（參與者）是否須要把操做結果進行真正的提交（好比將更新後的數據寫入磁盤等等）。
所以，二階段提交的算法思路能夠歸納爲：參與者將操做結果通知協調者，在由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做

參考

The Two-Phase Commit Protocol
二階段提交
分佈式理論(三) - 2PC協議
分佈式系統的一致性協議之 2PC 和 3PC