1 分散式事務

事務是作為單個邏輯單元執行的一組操作，要麼全部成功，要麼全部失敗

事務包含四個特性：原子性、一致性、隔離性、永續性

1.1 示例

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

上圖中包含了庫存和訂單兩個獨立的微服務，每個微服務維護了自己的資料庫。在交易系統的業務邏輯中，一個商品在下單之前需要先呼叫庫存服務，進行扣除庫存，再呼叫訂單服務，建立訂單記錄。

正常情況下，兩個資料庫各自更新成功，兩邊資料維持著一致性。

但是，在非正常情況下，有可能庫存的扣減完成了，隨後的訂單記錄卻因為某些原因插入失敗。這個時候，兩邊資料就失去了應有的一致性。

這種時候，為了保證資料的一致性，單資料來源的一致性，依靠單機事務來保證，多資料來源的一致性，依靠分散式事務來保證

1.2 什麼是分散式事務？

分散式事務用於在分散式系統中保證不同節點之間的資料一致性。

分散式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分散式事務協議。

1.3 分散式事務提交協議：XA協議

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

那麼XA協議究竟是什麼樣子呢？在XA協議中包含著兩個角色：事務協調者和事務參與者。讓我們來看一看他們之間的互動流程：

1.3.1 XA兩階段正向提交流程

第一階段：

在XA分散式事務的第一階段，作為事務協調者的節點會首先向所有的參與者節點發送Prepare請求。

在接到Prepare請求之後，每一個參與者節點會各自執行與事務有關的資料更新，寫入Undo Log和Redo Log。

如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回“完成”訊息。

當事務協調者接到了所有參與者的返回訊息，整個分散式事務將會進入第二階段

第二階段：

在XA分散式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那麼它將會向所有事務參與者發出Commit請求。

接到Commit請求之後，事務參與者節點會各自進行本地的事務提交，並釋放鎖資源。當本地事務完成提交後，將會向事務協調者返回“完成”訊息。

當事務協調者接收到所有事務參與者的“完成”反饋，整個分散式事務完成。

1.3.2 XA兩階段失敗提交流程

以上所描述的是XA兩階段提交的正向流程，接下來我們看一看失敗情況的處理流程：

第一階段：

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

第二階段：

於是在第二階段，事務協調節點向所有的事務參與者傳送Abort請求。

接收到Abort請求之後，各個事務參與者節點需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。

以上就是XA兩階段提交協議的詳細過程。

1.3.3 XA兩階段提交的不足

XA兩階段提交究竟有哪些不足呢？

1、效能問題

XA協議遵循強一致性。在事務執行過程中，各個節點佔用著資料庫資源，只有當所有節點準備完畢，事務協調者才會通知提交，參與者提交後釋放資源。

這樣的過程有著非常明顯的效能問題。

2、協調者單點故障問題

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

3、丟失訊息導致的不一致問題。

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

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

1、XA三階段提交

XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，並且引入了超時機制。一旦事物參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。

這樣有效解決了協調者單點故障的問題。但是效能問題和不一致的問題仍然沒有根本解決。

2、MQ事務

利用訊息中介軟體來非同步完成事務的後一半更新，實現系統的最終一致性。

這個方式避免了像XA協議那樣的效能問題。

3、TCC事務

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