假如沒有分散式事務
在一系列微服務系統當中，假如不存在分散式事務，會發生什麼呢？讓我們以網際網路中常用的交易業務為例子：

上圖中包含了庫存和訂單兩個獨立的微服務，每個微服務維護了自己的資料庫。在交易系統的業務邏輯中，一個商
品在下單之前需要先呼叫庫存服務，進行扣除庫存，再呼叫訂單服務，建立訂單記錄。
正常情況下，兩個資料庫各自更新成功，兩邊資料維持著一致性

什麼是分散式事務？
分散式事務用於在分散式系統中保證不同節點之間的資料一致性。分散式事務的實現有很多種，最具有代表性的是
由Oracle Tuxedo系統提出的XA分散式事務協議。
XA協議包含兩階段提交（2PC）和三階段提交（3PC）兩種實現，這裡我們重點介紹兩階段提交的具體過程。
XA兩階段提交（2PC）

在魔獸世界這款遊戲中，副本組團打BOSS的時候，為了更方便隊長與隊員們之間的協作，隊長可以發起一個“就位
確認”的操作：

以上就是魔獸世界當中組團打BOSS的確認流程。這個流程和XA分散式事務協議的兩階段提交非常相似。
那麼XA協議究竟是什麼樣子呢？在XA協議中包含著兩個角色：事務協調者和事務參與者。讓我們來看一看他們之
間的互動流程：
第一階段：

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

在XA分散式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那麼它將會向所有事務參與者發出
Commit請求。
接到Commit請求之後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將
會向事務協調者返回“完成”訊息。
當事務協調者接收到所有事務參與者的“完成”反饋，整個分散式事務完成。
以上所描述的是XA兩階段提交的正向流程，接下來我們看一看失敗情況的處理流程：

在XA的第一階段，如果某個事務參與者反饋失敗訊息，說明該節點的本地事務執行不成功，必須回滾。
於是在第二階段，事務協調節點向所有的事務參與者傳送Abort請求。接收到Abort請求之後，各個事務參與者節點
需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。
以上就是XA兩階段提交協議的詳細過程。
XA兩階段提交的不足

XA兩階段提交究竟有哪些不足呢？
1.效能問題
XA協議遵循強一致性。在事務執行過程中，各個節點佔用著資料庫資源，只有當所有節點準備完畢，事務協調者才
會通知提交，參與者提交後釋放資源。這樣的過程有著非常明顯的效能問題。
加微信獲取更多Java架構資料：jiang10086
微信獲取更多Java架構資料：jiang10086
2.協調者單點故障問題
事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處於
中間狀態無法完成事務。
3.丟失訊息導致的不一致問題。
在XA協議的第二個階段，如果發生區域性網路問題，一部分事務參與者收到了提交訊息，另一部分事務參與者沒收到
提交訊息，那麼就導致了節點之間資料的不一致。
如果避免XA兩階段提交的種種問題呢？有許多其他的分散式事務方案可供選擇：
XA三階段提交（3PC）
XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事物參與者遲遲沒有接
到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是效能問題和不一
致的問題仍然沒有根本解決。
MQ事務
利用訊息中介軟體來非同步完成事務的後一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的效能問
題。
TCC事務
TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似於XA兩階段提交，但是實現方式是在程式碼層面
來人為實現。