[TOC] # 分布式事務 OceanBase 數據庫使用兩階段提交協議來實現分布式事務，以分布式轉賬為例，假設服務器節點 A 上的賬戶 UA 向服務器節點 B 上的賬戶 UB 轉賬，則兩階段提交的步驟是： 第一階段，即 prepare 階段，節點 A 和節點 B 分別檢查賬戶 UA 和 UB 的狀態是否正常、賬戶 UA 的余額充足且可以轉出（沒有超限）、賬戶 UB 可以轉入（沒有被凍結），檢查通過則鎖定賬戶 UA 和 UB。 第二階段，即 commit 階段，如果在第一階段賬戶 UA 和 UB 的 prepare 操作都成功，則通知節點 A 對賬戶 UA 的余額進行扣減和通知節點 B 對賬戶 UB 的余額進行添加，轉賬成功；否則通知節點 A 和節點 B 對相應賬戶的操作進行回滾，轉賬取消。 然而，如果兩階段事務執行期間，某個節點，如 A，發生了故障，則無從知道 A 對賬戶 UA 的操作的狀況：賬戶 UA 的 prepare 可能沒有完成、或者完成且成功、或者完成但失敗，節點 A 可能很快恢復、也可能很長時間沒有恢復或者永久損壞，甚至無法簡單地判斷節點 A 是否故障或故障后是否恢復（例如監控節點并不總是能確定被監控節點的狀態，因為監控節點本身或其與被監控節點之間的通信可能異常），因此該分布式事務的執行結果是不確定的。 **Paxos + 兩階段提交協議**  OceanBase 數據庫將 Paxos 分布式一致性協議引入到兩階段提交，使得分布式事務具備自動容錯能力。如上圖所示，兩階段提交的每個參與者包含多個副本，副本之間通過 Paxos 協議實現高可用。當某個參與者節點發生故障時，通過 Paxos 協議可以很快（秒級）選舉出另外一個副本代替原有參與者繼續提供服務，并恢復原有參與者的狀態，從而確定分布式事務的執行結果并繼續推進兩階段提交協議的完成。  為了提升系統的分布式事務處理能力，降低延遲，OceanBase 數據庫進一步改進了傳統的兩階段提交協議，采用參與者即協調者的優化，讓每個分布式事務的第一個參與者承擔兩階段提交協議中協調者的工作。如上圖所示，傳統的兩階段提交協議包含獨立的協調者，協調者維護分布式事務的狀態，執行 prepare 和 commit 操作后應答客戶端，且每一個操作之前都需要記錄日志，用于協調者故障后恢復分布式事務的狀態，一次兩階段提交的延遲相當于 2 次 RPC 和 4 次寫日志操作。OceanBase 數據庫采用協調者無狀態設計，協調者不再維護分布式事務的狀態，而是在宕機恢復時，通過所有參與者的局部狀態動態構造分布式事務的全局狀態。這種方式避免了協調者寫日志，一次兩階段提交的延遲降低到 1 次 RPC 和 1 次寫日志操作。