[高級]關於分佈式事務、兩階段提交協議、三階提交協議

隨着大型網站的各類高併發訪問、海量數據處理等場景愈來愈多，如何實現網站的高可用、易伸縮、可擴展、安全等目標就顯得愈來愈重要。爲了解決這樣一系列問題，大型網站的架構也在不斷髮展。提升大型網站的高可用架構，不得不提的就是分佈式。在分佈式一致性一文中主要介紹了分佈式系統中存在的一致性問題。本文將簡單介紹如何有效的解決分佈式的一致性問題,其中包括什麼是分佈式事務，二階段提交和三階段提交。

分佈式一致性回顧

在分佈式系統中，爲了保證數據的高可用，一般，咱們會將數據保留多個副本(replica)，這些副本會放置在不一樣的物理的機器上。爲了對用戶提供正確的增\刪\改\差等語義，咱們須要保證這些放置在不一樣物理機器上的副本是一致的。

爲了解決這種分佈式一致性問題，前人在性能和數據一致性的反反覆覆權衡過程當中總結了許多典型的協議和算法。其中比較著名的有二階提交協議（Two Phase Commitment Protocol）、三階提交協議（Three Phase Commitment Protocol）和Paxos算法。

分佈式事務

分佈式事務是指會涉及到操做多個數據庫的事務。其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是爲了保證分佈式系統中的數據一致性。分佈式事務處理的關鍵是必須有一種方法能夠知道事務在任何地方所作的全部動做，提交或回滾事務的決定必須產生統一的結果（所有提交或所有回滾）

在分佈式系統中，各個節點之間在物理上相互獨立，經過網絡進行溝通和協調。因爲存在事務機制，能夠保證每一個獨立節點上的數據操做能夠知足ACID。可是，相互獨立的節點之間沒法準確的知道其餘節點中的事務執行狀況。因此從理論上講，兩臺機器理論上沒法達到一致的狀態。若是想讓分佈式部署的多臺機器中的數據保持一致性，那麼就要保證在全部節點的數據寫操做，要不所有都執行，要麼所有的都不執行。可是，一臺機器在執行本地事務的時候沒法知道其餘機器中的本地事務的執行結果。因此他也就不知道本次事務到底應該commit仍是 roolback。因此，常規的解決辦法就是引入一個「協調者」的組件來統一調度全部分佈式節點的執行。

XA規範

X/Open 組織（即如今的 Open Group ）定義了分佈式事務處理模型。 X/Open DTP 模型（ 1994 ）包括應用程序（ AP ）、事務管理器（ TM ）、資源管理器（ RM ）、通訊資源管理器（ CRM ）四部分。通常，常見的事務管理器（ TM ）是交易中間件，常見的資源管理器（ RM ）是數據庫，常見的通訊資源管理器（ CRM ）是消息中間件。 一般把一個數據庫內部的事務處理，如對多個表的操做，做爲本地事務看待。數據庫的事務處理對象是本地事務，而分佈式事務處理的對象是全局事務。 所謂全局事務，是指分佈式事務處理環境中，多個數據庫可能須要共同完成一個工做，這個工做便是一個全局事務，例如，一個事務中可能更新幾個不一樣的數據庫。對數據庫的操做發生在系統的各處但必須所有被提交或回滾。此時一個數據庫對本身內部所作操做的提交不只依賴自己操做是否成功，還要依賴與全局事務相關的其它數據庫的操做是否成功，若是任一數據庫的任一操做失敗，則參與此事務的全部數據庫所作的全部操做都必須回滾。 通常狀況下，某一數據庫沒法知道其它數據庫在作什麼，所以，在一個 DTP 環境中，交易中間件是必需的，由它通知和協調相關數據庫的提交或回滾。而一個數據庫只將其本身所作的操做（可恢復）影射到全局事務中。

XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。

二階提交協議和三階提交協議就是根據這一思想衍生出來的。能夠說二階段提交其實就是實現XA分佈式事務的關鍵(確切地說：兩階段提交主要保證了分佈式事務的原子性：即全部結點要麼全作要麼全不作)

2PC

二階段提交(Two-phaseCommit)是指，在計算機網絡以及數據庫領域內，爲了使基於分佈式系統架構下的全部節點在進行事務提交時保持一致性而設計的一種算法(Algorithm)。一般，二階段提交也被稱爲是一種協議(Protocol))。在分佈式系統中，每一個節點雖然能夠知曉本身的操做時成功或者失敗，卻沒法知道其餘節點的操做的成功或失敗。當一個事務跨越多個節點時，爲了保持事務的ACID特性，須要引入一個做爲協調者的組件來統一掌控全部節點(稱做參與者)的操做結果並最終指示這些節點是否要把操做結果進行真正的提交(好比將更新後的數據寫入磁盤等等)。所以，二階段提交的算法思路能夠歸納爲：參與者將操做成敗通知協調者，再由協調者根據全部參與者的反饋情報決定各參與者是否要提交操做仍是停止操做。

所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。

準備階段

事務協調者(事務管理器)給每一個參與者(資源管理器)發送Prepare消息，每一個參與者要麼直接返回失敗(如權限驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種「萬事俱備，只欠東風」的狀態。

能夠進一步將準備階段分爲如下三個步驟：

1）協調者節點向全部參與者節點詢問是否能夠執行提交操做(vote)，並開始等待各參與者節點的響應。

2）參與者節點執行詢問發起爲止的全部事務操做，並將Undo信息和Redo信息寫入日誌。（注意：若成功這裏其實每一個參與者已經執行了事務操做）

3）各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功，則它返回一個"贊成"消息；若是參與者節點的事務操做實際執行失敗，則它返回一個"停止"消息。

提交階段

若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾(Rollback)消息；不然，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操做，釋放全部事務處理過程當中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)

接下來分兩種狀況分別討論提交階段的過程。

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

1）協調者節點向全部參與者節點發出"正式提交(commit)"的請求。

2）參與者節點正式完成操做，並釋放在整個事務期間內佔用的資源。

3）參與者節點向協調者節點發送"完成"消息。

4）協調者節點受到全部參與者節點反饋的"完成"消息後，完成事務。

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

1）協調者節點向全部參與者節點發出"回滾操做(rollback)"的請求。

2）參與者節點利用以前寫入的Undo信息執行回滾，並釋放在整個事務期間內佔用的資源。

3）參與者節點向協調者節點發送"回滾完成"消息。

4）協調者節點受到全部參與者節點反饋的"回滾完成"消息後，取消事務。

　　無論最後結果如何，第二階段都會結束當前事務。

二階段提交看起來確實可以提供原子性的操做，可是不幸的事，二階段提交仍是有幾個缺點的：

一、同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。

二、單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

三、數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據部一致性的現象。

四、二階段沒法解決的問題：協調者再發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

因爲二階段提交存在着諸如同步阻塞、單點問題、腦裂等缺陷，因此，研究者們在二階段提交的基礎上作了改進，提出了三階段提交。

3PC

三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。

與兩階段提交不一樣的是，三階段提交有兩個改動點。

一、引入超時機制。同時在協調者和參與者中都引入超時機制。

二、在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

也就是說，除了引入超時機制以外，3PC把2PC的準備階段再次一分爲二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者若是能夠提交就返回Yes響應，不然返回No響應。

1.事務詢問 協調者向參與者發送CanCommit請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。

2.響應反饋 參與者接到CanCommit請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回Yes響應，並進入預備狀態。不然反饋No

PreCommit階段

協調者根據參與者的反應狀況來決定是否能夠記性事務的PreCommit操做。根據響應狀況，有如下兩種可能。

假如協調者從全部的參與者得到的反饋都是Yes響應，那麼就會執行事務的預執行。

1.發送預提交請求 協調者向參與者發送PreCommit請求，並進入Prepared階段。

2.事務預提交 參與者接收到PreCommit請求後，會執行事務操做，並將undo和redo信息記錄到事務日誌中。

3.響應反饋 若是參與者成功的執行了事務操做，則返回ACK響應，同時開始等待最終指令。

假若有任何一個參與者向協調者發送了No響應，或者等待超時以後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。

1.發送中斷請求 協調者向全部參與者發送abort請求。

2.中斷事務 參與者收到來自協調者的abort請求以後（或超時以後，仍未收到協調者的請求），執行事務的中斷。

doCommit階段

該階段進行真正的事務提交，也能夠分爲如下兩種狀況。

執行提交

1.發送提交請求 協調接收到參與者發送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送doCommit請求。

2.事務提交 參與者接收到doCommit請求以後，執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。

3.響應反饋 事務提交完以後，向協調者發送Ack響應。

4.完成事務 協調者接收到全部參與者的ack響應以後，完成事務。

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

1.發送中斷請求 協調者向全部參與者發送abort請求

2.事務回滾 參與者接收到abort請求以後，利用其在階段二記錄的undo信息來執行事務的回滾操做，並在完成回滾以後釋放全部的事務資源。

3.反饋結果 參與者完成事務回滾以後，向協調者發送ACK消息

4.中斷事務 協調者接收到參與者反饋的ACK消息以後，執行事務的中斷。

在doCommit階段，若是參與者沒法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時以後，會繼續進行事務的提交。（其實這個應該是基於機率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那麼協調者產生PreCommit請求的前提條件是他在第二階段開始以前，收到全部參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道你們其實都贊成修改了）因此，一句話歸納就是，當進入第三階段時，因爲網絡超時等緣由，雖然參與者沒有收到commit或者abort響應，可是他有理由相信：成功提交的概率很大。 ）

2PC與3PC的區別

相對於2PC，3PC主要解決的單點故障問題，並減小阻塞，由於一旦參與者沒法及時收到來自協調者的信息以後，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。可是這種機制也會致使數據一致性問題，由於，因爲網絡緣由，協調者發送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時以後執行了commit操做。這樣就和其餘接到abort命令並執行回滾的參與者之間存在數據不一致的狀況。

瞭解了2PC和3PC以後，咱們能夠發現，不管是二階段提交仍是三階段提交都沒法完全解決分佈式的一致性問題。Google Chubby的做者Mike Burrows說過，

there is only one consensus protocol, and that’s Paxos」 – all other approaches are just broken versions of Paxos.

意即世上只有一種一致性算法，那就是Paxos，全部其餘一致性算法都是Paxos算法的不完整版。後面的文章會介紹這個公認爲難於理解可是行之有效的Paxos算法。