分布式架構，剛性事務-2PC必須注意的問題及3PC詳細解

2PC必須注意的問題

咱們上文介紹了分布式事務的常見方案、類型劃分、2PC的起源和流程。但是不幸的是2PC還是存在幾個問題：

1、全流程的同步阻塞：不管是第一階段還是第二階段，所有參與節點都是事務阻塞型。當參與者占有公共資源時，其他第三方通路公共資源可能不得不處于阻塞狀态。

2、TM單點故障：由于全流程依賴TM的協調，一旦TM發生故障。參與者會一直阻塞下去。尤其在第二階段，TM發生故障，那麼所有的參與者還都處于鎖定事務資源的狀态中，而無法繼續完成事務操作。所有參與者必須等待TM重新上線(TM重新選舉)後才能繼續工作。

3、TM腦裂引起資料不一緻：在第二階段中，當TM向參與者發送commit請求之後，發生了局部網絡異常或者在發送commit請求過程中TM發生了故障，這會導緻隻有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務送出。于是整個分布式系統便出現了資料不一緻性的現象。

4、TM腦裂引起事務狀态不确定：TM再發出commit消息之後當機，而接收到這條消息的參與者同時也當機了。那麼即使通過選舉協定産生了新的TM，這條事務的狀态也是不确定的，沒人知道事務是否被已經送出。

3PC詳解來啦

一、3PC定義

2PC是CP的剛性事務，追求資料強一緻性。但是通過我們上面分析可以得知TM腦裂可能造成資料不一緻和事務狀态不确定問題。無法達到CP的完美狀态。是以業界就出現了3PC，用來處理TM腦裂引起的資料不一緻和事務狀态不确定問題。

因為3PC是為徹底解決的2PC的資料不一緻和事務狀态不确定問題而出現。根據這一個前提，加上筆者對3PC的了解，總結出3PC的注釋事項：

1）3PC確定任何分支下的資料一緻性

2）3PC確定任何分支最多3次握手得到最終結果(逾時機制)

3）RM逾時後的事務狀态必須從TM擷取。2PC隻有TM的逾時機制，3PC新增了參與者(RM)的逾時機制，一方面輔助解決了2PC的事務/事務問題，還能降低一定的同步阻塞問題。因為TM、RM雙向逾時機制，是以維基百科對3PC定義為“非阻塞”協定。

二、優雅的3PC流程

3PC 分成3個階段：CanCommit(準備階段)、PreCommit(對齊階段)、DoCommit(送出階段)；筆者根據資料對3階段進行比較合适的翻譯，非官方翻譯。

準備階段：跟2PC的表決階段很類似，TM向參與者發送commit請求，參與者如果可以送出就傳回Yes，否則傳回No，詢問逾時預設參與者為No。唯一差别在于SQL層面：準備階段隻做了SQL處理，并未記錄事務日志(Undo 和Redo)

對齊階段：TM 和 各個參與者對齊事務狀态，TM 通知各個參與者事務最終狀态，各個參與者如果一緻未收到事務對齊通知，會在逾時後從TM反查事務狀态實作事務狀态對齊。在SQL層面：事務狀态對齊後，記錄事務日志(Undo 和Redo)

送出階段：該階段進行真正的事務送出。根據第二階段得到的事務狀态結果，各參與者根據TM的通知指令進行送出/abort或者逾時後自動送出/abort。

下圖是筆者根據資料和個人了解整理出來的一個自認為比較合理的3PC流程圖：

三、總結

或許3PC也不完美，網上有好多各版本的3PC的流程圖和解釋。有的甚至還存在明顯的問題，為3PC的了解帶來了更大的苦難。身為架構師，就需要去追尋本質，了解3PC的前世今生，抓住3PC的本質，就很容易了解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算法的不完整版。