原文：什麼是分散式事務？

分散式事務用於在分散式系統中保證不同節點之間的資料一致性。分散式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分散式事務協議。

XA協議包含兩階段提交（2PC）和三階段提交（3PC）兩種實現，這裡我們重點介紹兩階段提交的具體過程。

在XA協議中包含著兩個角色：事務協調者和事務參與者。

XA兩階段提交的正向流程

第一階段

1. 在XA分散式事務的第一階段，作為事務協調者的節點會首先向所有的參與者節點傳送Prepare請求。
2. 在接到Prepare請求之後，每一個參與者節點會各自執行與事務有關的資料更新，寫入Undo Log和Redo Log。如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回“完成”訊息。
3. 當事務協調者接到了所有參與者的返回訊息，整個分散式事務將會進入第二階段。

第二階段

1. 在XA分散式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那麼它將會向所有事務參與者發出Commit請求。
2. 接到Commit請求之後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將會向事務協調者返回“完成”訊息。
3. 當事務協調者接收到所有事務參與者的“完成”反饋，整個分散式事務完成。

XA兩階段提交的失敗情況的處理流程

第一階段

在XA的第一階段，如果某個事務參與者反饋失敗訊息，說明該節點的本地事務執行不成功，必須回滾。

第二階段

於是在第二階段，事務協調節點向所有的事務參與者傳送Abort請求。接收到Abort請求之後，各個事務參與者節點需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。

XA兩階段提交的不足

1.效能問題
XA協議遵循強一致性。在事務執行過程中，各個節點佔用著資料庫資源，只有當所有節點準備完畢，事務協調者才會通知提交，參與者提交後釋放資源。這樣的過程有著非常明顯的效能問題。

2.協調者單點故障問題
事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處於中間狀態無法完成事務。

3.丟失訊息導致的不一致問題。
在XA協議的第二個階段，如果發生區域性網路問題，一部分事務參與者收到了提交訊息，另一部分事務參與者沒收到提交訊息，那麼就導致了節點之間資料的不一致。

其他的分散式事務方案

如果避免XA兩階段提交的種種問題呢？有許多其他的分散式事務方案可供選擇：

1.XA三階段提交

XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事物參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是效能問題和不一致的問題仍然沒有根本解決。

2.MQ事務

利用訊息中介軟體來非同步完成事務的後一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的效能問題。

3.TCC事務

TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似於XA兩階段提交，但是實現方式是在程式碼層面來人為實現。