分佈式事務(1)---2PC和3PC原理

分佈式事務(1)---2PC和3PC原理

分佈式事物基本理論:基本遵循CPA理論，採用柔性事物特徵，軟狀態或者最終一致性特色保證分佈式事物一致性問題。

分佈式事物常看法決方案:

1. 2PC兩段提交協議

2. 3PC三段提交協議(彌補兩端提交協議缺點)

3. TCC或者GTS(阿里)

4. 消息中間件最終一致性

5. 使用LCN解決分佈式事物，理念「LCN並不生產事務,LCN只是本地事務的搬運工」。

1、兩階段提交（2PC）

兩階段提交又稱2PC,2PC是一個很是經典的強一致、中心化的原子提交協議。

這裏所說的中心化是指協議中有兩類節點：一個是中心化協調者節點（coordinator）和N個參與者節點（partcipant）。

兩個階段：第一階段：投票階段 和第二階段：提交/執行階段。

舉例 訂單服務A，須要調用 支付服務B 去支付，支付成功則處理購物訂單爲待發貨狀態，不然就須要將購物訂單處理爲失敗狀態。

那麼看2PC階段是如何處理的

一、第一階段：投票階段

第一階段主要分爲3步

1）事務詢問

協調者 向全部的 參與者 發送事務預處理請求，稱之爲Prepare，並開始等待各 參與者 的響應。

2）執行本地事務

各個 參與者 節點執行本地事務操做,但在執行完成後並不會真正提交數據庫本地事務，而是先向 協調者 報告說：「我這邊能夠處理了/我這邊不能處理」。.

3）各參與者向協調者反饋事務詢問的響應

若是 參與者 成功執行了事務操做,那麼就反饋給協調者 Yes 響應,表示事務能夠執行,若是沒有 參與者 成功執行事務,那麼就反饋給協調者 No 響應,表示事務不能夠執行。

第一階段執行完後，會有兩種可能。一、全部都返回Yes. 二、有一個或者多個返回No。

二、第二階段：提交/執行階段（成功流程）

成功條件：全部參與者都返回Yes。

第二階段主要分爲兩步

​ 1)全部的參與者反饋給協調者的信息都是Yes,那麼就會執行事務提交

​ 協調者 向 全部參與者 節點發出Commit請求.

​ 2)事務提交

​ 參與者 收到Commit請求以後,就會正式執行本地事務Commit操做,並在完成提交以後釋放整個事務執行期間佔用的事務資源。

三、第二階段：提交/執行階段（異常流程）

異常條件：任何一個 參與者 向 協調者 反饋了 No 響應,或者等待超時以後,協調者還沒有收到全部參與者的反饋響應。

異常流程第二階段也分爲兩步

1)發送回滾請求

​ 協調者 向全部參與者節點發出 RoollBack 請求.

​ 2)事務回滾

​ 參與者 接收到RoollBack請求後,會回滾本地事務。

四、2PC缺點

經過上面的演示，很容易想到2pc所帶來的缺陷

1）性能問題

不管是在第一階段的過程當中,仍是在第二階段,全部的參與者資源和協調者資源都是被鎖住的,只有當全部節點準備完畢，事務 協調者 纔會通知進行全局提交，

參與者 進行本地事務提交後纔會釋放資源。這樣的過程會比較漫長，對性能影響比較大。

2）單節點故障

因爲協調者的重要性，一旦 協調者 發生故障。參與者 會一直阻塞下去。尤爲在第二階段，協調者 發生故障，那麼全部的 參與者 還都處於

鎖定事務資源的狀態中，而沒法繼續完成事務操做。（雖然協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

2PC出現單點問題的三種狀況

(1)協調者正常,參與者宕機

​ 因爲 協調者 沒法收集到全部 參與者 的反饋，會陷入阻塞狀況。

​ 解決方案:引入超時機制,若是協調者在超過指定的時間尚未收到參與者的反饋,事務就失敗,向全部節點發送終止事務請求。

(2)協調者宕機,參與者正常

​ 不管處於哪一個階段，因爲協調者宕機，沒法發送提交請求，全部處於執行了操做可是未提交狀態的參與者都會陷入阻塞狀況.

​ 解決方案:引入協調者備份,同時協調者需記錄操做日誌.當檢測到協調者宕機一段時間後，協調者備份取代協調者，並讀取操做日誌，向全部參與者詢問狀態。

(3)協調者和參與者都宕機

1) 發生在第一階段： 由於第一階段，全部參與者都沒有真正執行commit，因此只需從新在剩餘的參與者中從新選出一個協調者，新的協調者在從新執行第一階段和第二階段就能夠了。

2)發生在第二階段 而且 掛了的參與者在掛掉以前沒有收到協調者的指令。也就是上面的第4步掛了，這是可能協調者尚未發送第4步就掛了。這種情形下，新的協調者從新執行第一階段和第二階段操做。

3)發生在第二階段 而且 有部分參與者已經執行完commit操做。就比如這裏訂單服務A和支付服務B都收到協調者 發送的commit信息，開始真正執行本地事務commit,但突發狀況，Acommit成功，B確掛了。這個時候目前來說數據是不一致的。雖然這個時候能夠再經過手段讓他和協調者通訊，再想辦法把數據搞成一致的，可是，這段時間內他的數據狀態已是不一致的了！ 2PC 沒法解決這個問題。

2、三階段提交(3PC)

三階段提交協議（3PC）主要是爲了解決兩階段提交協議的阻塞問題，2pc存在的問題是當協做者崩潰時，參與者不能作出最後的選擇。所以參與者可能在協做者恢復以前保持阻塞。三階段提交（Three-phase commit），是二階段提交（2PC）的改進版本。

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

一、 引入超時機制。同時在協調者和參與者中都引入超時機制。
二、在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

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

一、CanCommit階段

以前2PC的一階段是本地事務執行結束後，最後不Commit,等其它服務都執行結束並返回Yes，由協調者發生commit才真正執行commit。而這裏的CanCommit指的是 嘗試獲取數據庫鎖 若是能夠，就返回Yes。

這階段主要分爲2步

事務詢問 協調者 向 參與者 發送CanCommit請求。詢問是否能夠執行事務提交操做。而後開始等待 參與者 的響應。
響應反饋 參與者 接到CanCommit請求以後，正常狀況下，若是其自身認爲能夠順利執行事務，則返回Yes響應，並進入預備狀態。不然反饋No

二、PreCommit階段

在階段一中，若是全部的參與者都返回Yes的話，那麼就會進入PreCommit階段進行事務預提交。這裏的PreCommit階段 跟上面的第一階段是差很少的，只不過這裏 協調者和參與者都引入了超時機制 （2PC中只有協調者能夠超時，參與者沒有超時機制）。

三、DoCommit階段

這裏跟2pc的階段二是差很少的。

總結

相比較2PC而言，3PC對於協調者（Coordinator）和參與者（Partcipant）都設置了超時時間，而2PC只有協調者才擁有超時機制。這解決了一個什麼問題呢？

這個優化點，主要是避免了參與者在長時間沒法與協調者節點通信（協調者掛掉了）的狀況下，沒法釋放資源的問題，由於參與者自身擁有超時機制會在超時後，

自動進行本地commit從而進行釋放資源。而這種機制也側面下降了整個事務的阻塞時間和範圍。

另外，經過CanCommit、PreCommit、DoCommit三個階段的設計，相較於2PC而言，多設置了一個緩衝階段保證了在最後提交階段以前各參與節點的狀態是一致的。

以上就是3PC相對於2PC的一個提升（相對緩解了2PC中的前兩個問題），可是3PC依然沒有徹底解決數據不一致的問題。

參考

一、分佈式事務：深刻理解什麼是2PC、3PC

二、分佈式事務、3pc

三、對分佈式事務及兩階段提交、三階段提交的理解

四、分佈式理論基礎：2PC和3PC

只要本身變優秀了，其餘的事情纔會跟着好起來（上將5）