分散式事務一致性：二階段提交協議（2PC）
阿新 • • 發佈：2018-12-29
文章目錄
分散式系統開發不可避免會遇到分散式事務，目前業界都沒有徹底解決的方案，只有各種協議（XA、TCC、Paxos、zab等）、衍生的框架（LCN、tcc-transaction等），最近一直在看相關的書籍和資料，想盡量簡單的整理下相關內容。先整理個最基礎、也是比較重要的、基於XA協議的二階段提交（2PC）。
“2PC可以說是種演算法，也可以說是一種協議。” — —百度百科
一、概念
二階段提交協議把分散式事務分為兩個階段，1準備階段，2提交階段，準備階段和提交階段都是事務 管理器發起的（協調者），參與事務的資源（協調者）。
- 準備階段： 協調者像參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，則會 寫redo或者undo日誌（redo日誌記錄資料修改後的值，以應對資料庫修改資料過程中宕機，恢復後可以通過redo日誌將緩衝區的修改後的值刷到磁碟上，undo日誌記錄資料修改前的值，是用來回滾的）。然後鎖定資源，執行操作，但不會提交。
- 提交階段： 如果每個參與者明確返回準備成功，協調者會向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定的資源。如果任何一個參與者明確返回失敗， 則協調者向參與者發起中止指令，參與者取消已經變更的事務，執行undo日誌，釋放鎖定的資源。
二、優缺點
優點：
原理簡單。
缺點：
二階段提交協議在準備階段鎖定資源，這是一個重量級的操作，能保證強一致性，但是實現起來複雜，成本較高，不夠靈活，更重要的是它有如下幾個致命的問題：
- 阻塞：節點在等待訊息時，什麼都做不了。
- 單點故障：協調者宕機，參與者沒有協調者指揮，會一直被阻塞。儘管可以通過選舉新的協調者替代原有協調者，但還是有其他情況處理不了。
- 腦裂：協調者傳送提交命令，有的參與者接受到並執行了事務，有的沒接收到就沒執行事務，多個參與者之間產生不一致。
三、總結
正常情況下能保證系統的強一致性，但異常後，需要人工干預，可用性不夠好。