分散式架構，剛性事務-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演算法的不完整版。

更多免費資料及影片