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算法的不完整版。
作者介紹
林淮川
畢業於西安交通大學；前大樹金融高級架構師；前大樹金融技術委員會開創者；前大樹金融供應鏈金融技術總監；前天陽宏業交易事業部技術主管；多年互聯網金融行業（ToB）經驗。