引言：2PC必須注意的問題算法
我們上文介紹了分佈式事務的常見方案、類型劃分、2PC的起源和流程。可是不幸的是2PC仍是存在幾個問題：網絡
一、全流程的同步阻塞：不論是第一階段仍是第二階段，全部參與節點都是事務阻塞型。當參與者佔有公共資源時，其餘第三方訪問公共資源可能不得不處於阻塞狀態。架構
二、TM單點故障：因爲全流程依賴TM的協調，一旦TM發生故障。參與者會一直阻塞下去。尤爲在第二階段，TM發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。全部參與者必須等待TM從新上線(TM從新選舉)後才能繼續工做。app
三、TM腦裂引發數據不一致：在第二階段中，當TM向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中TM發生了故障，這會致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據不一致性的現象。分佈式
四、TM腦裂引發事務狀態不肯定：TM再發出commit消息以後宕機，而接收到這條消息的參與者同時也宕機了。那麼即便經過選舉協議產生了新的TM，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。翻譯
一、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定義爲「非阻塞」協議。同步
2、優雅的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流程圖：
3、總結
或許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）經驗。