2PC&&3PC

原文連接:https://www.jianshu.com/p/dd6a340e50b2

XA規範

XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規範（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。
二階提交協議和三階提交協議就是根據這一思想衍生出來的。能夠說二階段提交其實就是實現XA分佈式事務的關鍵(確切地說：兩階段提交主要保證了分佈式事務的原子性：即全部結點要麼全作要麼全不作)

2PC

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

準備階段

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

能夠進一步將準備階段分爲如下三個步驟：
1）協調者節點向全部參與者節點詢問是否能夠執行提交操做(vote)，並開始等待各參與者節點的響應。

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

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

提交階段

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

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

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

提交階段

若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾(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命令並執行回滾的參與者之間存在數據不一致的狀況。

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