本文提綱如下

• 0. 前言

• 1. 單數據源事務 & 多數據源事務

• 2. 常見分布式事務解決方案

• 2.1. 分布式事務模型

• 2.2. 二將軍問題和冪等性

• 2.3. 兩階段提交（2PC） & 三階段提交（3PC）方案

• 2.4. TCC 方案

• 2.5. 事務狀態表方案

• 2.6. 基于消息中間件的原理最終一致性事務方案

• 3. Seata in AT mode 的實現

• 3.1. Seata in AT mode 工作流程概述

• 3.2. Seata in AT mode 工作流程詳述

• 4. 結束語

0. 前言

從 CPU 到內存、字張圖到磁盤、讓徹到操作系統、底掌到網絡，握分計算機系統處處存在不可靠因素。布式工程師和科學家努力使用各種軟硬件方法對抗這種不可靠因素，事務保證數據和指令被正確地處理。原理在網絡領域有 TCP 可靠傳輸協議、字張圖在存儲領域有 Raid5 和 Raid6 算法、在數據庫領域有基于 ARIES 算法理論實現的事務機制……

這篇文章先介紹單機數據庫事務的 ACID 特性，然后指出分布式場景下操作多數據源面臨的困境，引出分布式系統中常用的分布式事務解決方案，這些解決方案可以保證業務代碼在操作多個數據源的時候，能夠像操作單個數據源一樣，具備 ACID 特性。文章在最后給出業界較為成熟的分布式事務框架——Seata 的 AT 模式全局事務的實現。

1. 單數據源事務 & 多數據源事務

如果一個應用程序在一次業務流中通過連接驅動和數據源接口只連接并查詢（這里的查詢是廣義的，包括增刪查改等）一個特定的數據庫，該應用程序就可以利用數據庫提供的事務機制（如果數據庫支持事務的話）保證對庫中記錄所進行的操作的可靠性，這里的可靠性有四種語義：

- 原子性，A

- 一致性，C

- 隔離性，I

- 持久性，D

筆者在這里不再對這四種語義進行解釋，了解單數據源事務及其 ACID 特性是讀者閱讀這篇文章的前提。單個數據庫實現自身的事務特性是一個復雜又微妙的過程，例如 MySQL 的 InnoDB 引擎通過 Undo Log + Redo Log + ARIES 算法來實現。這是一個很宏大的話題，不在本文的描述范圍，讀者有興趣的話可自行研究。

單數據源事務也可以叫做單機事務，或者本地事務。

在分布式場景下，一個系統由多個子系統構成，每個子系統有獨立的數據源。多個子系統之間通過互相調用來組合出更復雜的業務。在時下流行的微服務系統架構中，每一個子系統被稱作一個微服務，同樣每個微服務都維護自己的數據庫，以保持獨立性。

例如，一個電商系統可能由購物微服務、庫存微服務、訂單微服務等組成。購物微服務通過調用庫存微服務和訂單微服務來整合出購物業務。用戶請求購物微服務商完成下單時，購物微服務一方面調用庫存微服務扣減相應商品的庫存數量，另一方面調用訂單微服務插入訂單記錄（為了后文描述分布式事務解決方案的方便，這里給出的是一個最簡單的電商系統微服務劃分和最簡單的購物業務流程，后續的支付、物流等業務不在考慮范圍內）。電商系統模型如下圖所示：

在用戶購物的業務場景中，shopping-service 的業務涉及兩個數據庫：庫存庫（repo_db）和訂單庫（repo_db），也就是 g 購物業務是調用多數據源來組合而成的。作為一個面向消費者的系統，電商系統要保證購物業務的高度可靠性，這里的可靠性同樣有 ACID 四種語義。

但是一個數據庫的本地事務機制僅僅對落到自己身上的查詢操作（這里的查詢是廣義的，包括增刪改查等）起作用，無法干涉對其他數據庫的查詢操作。所以，數據庫自身提供的本地事務機制無法確保業務對多數據源全局操作的可靠性。

基于此，針對多數據源操作提出的分布式事務機制就出現了。

分布式事務也可以叫做全局事務。

2. 常見分布式事務解決方案

2.1. 分布式事務模型

描述分布式事務，常常會使用以下幾個名詞：

- 事務參與者：例如每個數據庫就是一個事務參與者

- 事務協調者：訪問多個數據源的服務程序，例如 shopping-service 就是事務協調者

- 資源管理器（Resource Manager, RM）：通常與事務參與者同義

- 事務管理器（Transaction Manager, TM）：通常與事務協調者同義

在分布式事務模型中，一個 TM 管理多個 RM，即一個服務程序訪問多個數據源；TM 是一個全局事務管理器，協調多方本地事務的進度，使其共同提交或回滾，最終達成一種全局的 ACID 特性。

2.2. 二將軍問題和冪等性

二將軍問題是網絡領域的一個經典問題，用于表達計算機網絡中互聯協議設計的微妙性和復雜性。這里給出一個二將軍問題的簡化版本：

一支白軍被圍困在一個山谷中，山谷的左右兩側是藍軍。困在山谷中的白軍人數多于山谷兩側的任意一支藍軍，而少于兩支藍軍的之和。若一支藍軍對白軍單獨發起進攻，則必敗無疑；但若兩支藍軍同時發起進攻，則可取勝。兩只藍軍的總指揮位于山谷左側，他希望兩支藍軍同時發起進攻，這樣就要把命令傳到山谷右側的藍軍，以告知發起進攻的具體時間。假設他們只能派遣士兵穿越白軍所在的山谷（唯一的通信信道）來傳遞消息，那么在穿越山谷時，士兵有可能被俘虜。

只有當送信士兵成功往返后，總指揮才能確認這場戰爭的勝利（上方圖）?，F在問題來了，派遣出去送信的士兵沒有回來，則左側藍軍中的總指揮能不能決定按命令中約定的時間發起進攻？

答案是不確定，派遣出去送信的士兵沒有回來，他可能遇到兩種狀況：

1）命令還沒送達就被俘虜了（中間圖），這時候右側藍軍根本不知道要何時進攻；

2）命令送達，但返回途中被俘虜了（下方圖），這時候右側藍軍知道要何時進攻，但左側藍軍不知道右側藍軍是否知曉進攻時間。

類似的問題在計算機網絡中普遍存在，例如發送者給接受者發送一個 HTTP 請求，或者 MySQL 客戶端向 MySQL 服務器發送一條插入語句，然后超時了沒有得到響應。請問服務器是寫入成功了還是失敗了？答案是不確定，有以下幾種情況：

1）可能請求由于網絡故障根本沒有送到服務器，因此寫入失敗；

2）可能服務器收到了，也寫入成功了，但是向客戶端發送響應前服務器宕機了；

3）可能服務器收到了，也寫入成功了，也向客戶端發送了響應，但是由于網絡故障未送到客戶端。

無論哪種場景，在客戶端看來都是一樣的結果：它發出的請求沒有得到響應。為了確保服務端成功寫入數據，客戶端只能重發請求，直至接收到服務端的響應。

類似的問題問題被稱為網絡二將軍問題。

網絡二將軍問題的存在使得消息的發送者往往要重復發送消息，直到收到接收者的確認才認為發送成功，但這往往又會導致消息的重復發送。例如電商系統中訂單模塊調用支付模塊扣款的時候，如果網絡故障導致二將軍問題出現，扣款請求重復發送，產生的重復扣款結果顯然是不能被接受的。因此要保證一次事務中的扣款請求無論被發送多少次，接收方有且只執行一次扣款動作，這種保證機制叫做接收方的冪等性。

2.3. 兩階段提交（2PC） & 三階段提交（3PC）方案

2PC 是一種實現分布式事務的簡單模型，這兩個階段是：

1）準備階段：事務協調者向各個事務參與者發起詢問請求：“我要執行全局事務了，這個事務涉及到的資源分布在你們這些數據源中，分別是……，你們準備好各自的資源（即各自執行本地事務到待提交階段）”。各個參與者協調者回復 yes（表示已準備好，允許提交全局事務）或 no（表示本參與者無法拿到全局事務所需的本地資源，因為它被其他本地事務鎖住了）或超時。

2）提交階段：如果各個參與者回復的都是 yes，則協調者向所有參與者發起事務提交操作，然后所有參與者收到后各自執行本地事務提交操作并向協調者發送 ACK；如果任何一個參與者回復 no 或者超時，則協調者向所有參與者發起事務回滾操作，然后所有參與者收到后各自執行本地事務回滾操作并向協調者發送 ACK。

2PC 的流程如下圖所示：

從上圖可以看出，要實現 2PC，所有的參與者都要實現三個接口：

• Prepare()：TM 調用該接口詢問各個本地事務是否就緒

• Commit()：TM 調用該接口要求各個本地事務提交

• Rollback()：TM 調用該接口要求各個本地事務回滾

可以將這三個接口簡單地（但不嚴謹地）理解成 XA 協議。XA 協議是 X/Open 提出的分布式事務處理標準。MySQL、Oracle、DB2 這些主流數據庫都實現了 XA 協議，因此都能被用于實現 2PC 事務模型。

2PC 簡明易懂，但存在如下的問題：

1）性能差，在準備階段，要等待所有的參與者返回，才能進入階段二，在這期間，各個參與者上面的相關資源被排他地鎖住，參與者上面意圖使用這些資源的本地事務只能等待。因為存在這種同步阻塞問題，所以影響了各個參與者的本地事務并發度；

2）準備階段完成后，如果協調者宕機，所有的參與者都收不到提交或回滾指令，導致所有參與者“不知所措”；

3）在提交階段，協調者向所有的參與者發送了提交指令，如果一個參與者未返回 ACK，那么協調者不知道這個參與者內部發生了什么（由于網絡二將軍問題的存在，這個參與者可能根本沒收到提交指令，一直處于等待接收提交指令的狀態；也可能收到了，并成功執行了本地提交，但返回的 ACK 由于網絡故障未送到協調者上），也就無法決定下一步是否進行全體參與者的回滾。

2PC 之后又出現了 3PC，把兩階段過程變成了三階段過程，分別是：詢問階段、準備階段、提交或回滾階段，這里不再詳述。3PC 利用超時機制解決了 2PC 的同步阻塞問題，避免資源被永久鎖定，進一步加強了整個事務過程的可靠性。但是 3PC 同樣無法應對類似的宕機問題，只不過出現多數據源中數據不一致問題的概率更小。

2PC 除了性能和可靠性上存在問題，它的適用場景也很局限，它要求參與者實現了 XA 協議，例如使用實現了 XA 協議的數據庫作為參與者可以完成 2PC 過程。但是在多個系統服務利用 api 接口相互調用的時候，就不遵守 XA 協議了，這時候 2PC 就不適用了。所以 2PC 在分布式應用場景中很少使用。

所以前文提到的電商場景無法使用 2PC，因為 shopping-service 通過 RPC 接口或者 Rest 接口調用 repo-service 和 order-service 間接訪問 repo_db 和 order_db。除非 shopping-service 直接配置 repo_db 和 order_db 作為自己的數據庫。

2.4. TCC 方案

描述 TCC 方案使用的電商微服務模型如下圖所示，在這個模型中，shopping-service 是事務協調者，repo-service 和 order-service 是事務參與者。

上文提到，2PC 要求參與者實現了 XA 協議，通常用來解決多個數據庫之間的事務問題，比較局限。在多個系統服務利用 api 接口相互調用的時候，就不遵守 XA 協議了，這時候 2PC 就不適用了。現代企業多采用分布式的微服務，因此更多的是要解決多個微服務之間的分布式事務問題。

TCC 就是一種解決多個微服務之間的分布式事務問題的方案。TCC 是 Try、Confirm、Cancel 三個詞的縮寫，其本質是一個應用層面上的 2PC，同樣分為兩個階段：

1）階段一：準備階段。協調者調用所有的每個微服務提供的 try 接口，將整個全局事務涉及到的資源鎖定住，若鎖定成功 try 接口向協調者返回 yes。

2）階段二：提交階段。若所有的服務的 try 接口在階段一都返回 yes，則進入提交階段，協調者調用所有服務的 confirm 接口，各個服務進行事務提交。如果有任何一個服務的 try 接口在階段一返回 no 或者超時，則協調者調用所有服務的 cancel 接口。

TCC 的流程如下圖所示：

這里有個關鍵問題，既然 TCC 是一種服務層面上的 2PC，它是如何解決 2PC 無法應對宕機問題的缺陷的呢？答案是不斷重試。由于 try 操作鎖住了全局事務涉及的所有資源，保證了業務操作的所有前置條件得到滿足，因此無論是 confirm 階段失敗還是 cancel 階段失敗都能通過不斷重試直至 confirm 或 cancel 成功（所謂成功就是所有的服務都對 confirm 或者 cancel 返回了 ACK）。

這里還有個關鍵問題，在不斷重試 confirm 和 cancel 的過程中（考慮到網絡二將軍問題的存在）有可能重復進行了 confirm 或 cancel，因此還要再保證 confirm 和 cancel 操作具有冪等性，也就是整個全局事務中，每個參與者只進行一次 confirm 或者 cancel。實現 confirm 和 cancel 操作的冪等性，有很多解決方案，例如每個參與者可以維護一個去重表（可以利用數據庫表實現也可以使用內存型 KV 組件實現），記錄每個全局事務（以全局事務標記 XID 區分）是否進行過 confirm 或 cancel 操作，若已經進行過，則不再重復執行。

TCC 由支付寶團隊提出，被廣泛應用于金融系統中。我們用銀行賬戶余額購買基金時，會注意到銀行賬戶中用于購買基金的那部分余額首先會被凍結，由此我們可以猜想，這個過程大概就是 TCC 的第一階段。

2.5. 事務狀態表方案

另外有一種類似 TCC 的事務解決方案，借助事務狀態表來實現。假設要在一個分布式事務中實現調用 repo-service 扣減庫存、調用 order-service 生成訂單兩個過程。在這種方案中，協調者 shopping-service 維護一張如下的事務狀態表：

初始狀態為 1，每成功調用一個服務則更新一次狀態，最后所有的服務調用成功，狀態更新到 3。

有了這張表，就可以啟動一個后臺任務，掃描這張表中事務的狀態，如果一個分布式事務一直（設置一個事務周期閾值）未到狀態 3，說明這條事務沒有成功執行，于是可以重新調用 repo-service 扣減庫存、調用 order-service 生成訂單。直至所有的調用成功，事務狀態到 3。

如果多次重試仍未使得狀態到 3，可以將事務狀態置為 error，通過人工介入進行干預。

由于存在服務的調用重試，因此每個服務的接口要根據全局的分布式事務 ID 做冪等，原理同 2.4 節的冪等性實現。

2.6. 基于消息中間件的最終一致性事務方案

無論是 2PC & 3PC 還是 TCC、事務狀態表，基本都遵守 XA 協議的思想，即這些方案本質上都是事務協調者協調各個事務參與者的本地事務的進度，使所有本地事務共同提交或回滾，最終達成一種全局的 ACID 特性。在協調的過程中，協調者需要收集各個本地事務的當前狀態，并根據這些狀態發出下一階段的操作指令。

但是這些全局事務方案由于操作繁瑣、時間跨度大，或者在全局事務期間會排他地鎖住相關資源，使得整個分布式系統的全局事務的并發度不會太高。這很難滿足電商等高并發場景對事務吞吐量的要求，因此互聯網服務提供商探索出了很多與 XA 協議背道而馳的分布式事務解決方案。其中利用消息中間件實現的最終一致性全局事務就是一個經典方案。

為了表現出這種方案的精髓，我將使用如下的電商系統微服務結構來進行描述：

在這個模型中，用戶不再是請求整合后的 shopping-service 進行下單，而是直接請求 order-service 下單，order-service 一方面添加訂單記錄，另一方面會調用 repo-service 扣減庫存。

這種基于消息中間件的最終一致性事務方案常常被誤解成如下的實現方式：

這種實現方式的流程是：

1）order-service 負責向 MQ server 發送扣減庫存消息（repo_deduction_msg）；repo-service 訂閱 MQ server 中的扣減庫存消息，負責消費消息。

2）用戶下單后，order-service 先執行插入訂單記錄的查詢語句，后將 repo_deduction_msg 發到消息中間件中，這兩個過程放在一個本地事務中進行，一旦“執行插入訂單記錄的查詢語句”失敗，導致事務回滾，“將 repo_deduction_msg 發到消息中間件中”就不會發生；同樣，一旦“將 repo_deduction_msg 發到消息中間件中”失敗，拋出異常，也會導致“執行插入訂單記錄的查詢語句”操作回滾，最終什么也沒有發生。

3）repo-service 接收到 repo_deduction_msg 之后，先執行庫存扣減查詢語句，后向 MQ sever 反饋消息消費完成 ACK，這兩個過程放在一個本地事務中進行，一旦“執行庫存扣減查詢語句”失敗，導致事務回滾，“向 MQ sever 反饋消息消費完成 ACK”就不會發生，MQ server 在 Confirm 機制的驅動下會繼續向 repo-service 推送該消息，直到整個事務成功提交；同樣，一旦“向 MQ sever 反饋消息消費完成 ACK”失敗，拋出異常，也對導致“執行庫存扣減查詢語句”操作回滾，MQ server 在 Confirm 機制的驅動下會繼續向 repo-service 推送該消息，直到整個事務成功提交。

這種做法看似很可靠。但沒有考慮到網絡二將軍問題的存在，有如下的缺陷：

1）存在網絡的 2 將軍問題，上面第 2）步中 order-service 發送 repo_deduction_msg 消息失敗，對于發送方 order-service 來說，可能是消息中間件沒有收到消息；也可能是中間件收到了消息，但向發送方 order-service 響應的 ACK 由于網絡故障沒有被 order-service 收到。因此 order-service 貿然進行事務回滾，撤銷“執行插入訂單記錄的查詢語句”，是不對的，因為 repo-service 那邊可能已經接收到 repo_deduction_msg 并成功進行了庫存扣減，這樣 order-service 和 repo-service 兩方就產生了數據不一致問題。

2）repo-service 和 order-service 把網絡調用（與 MQ server 通信）放在本地數據庫事務里，可能會因為網絡延遲產生數據庫長事務，影響數據庫本地事務的并發度。

以上是被誤解的實現方式，下面給出正確的實現方式，如下所示：

上圖所示的方案，利用消息中間件如 rabbitMQ 來實現分布式下單及庫存扣減過程的最終一致性。對這幅圖做以下說明：

1）order-service 中，

在?t_order?表添加訂單記錄?&&

在?t_local_msg?添加對應的扣減庫存消息

這兩個過程要在一個事務中完成，保證過程的原子性。同樣，repo-service 中，

檢查本次扣庫存操作是否已經執行過?&&

執行扣減庫存如果本次扣減操作沒有執行過?&&

寫判重表?&&

向?MQ?sever?反饋消息消費完成?ACK

這四個過程也要在一個事務中完成，保證過程的原子性。

2）order-service 中有一個后臺程序，源源不斷地把消息表中的消息傳送給消息中間件，成功后則刪除消息表中對應的消息。如果失敗了，也會不斷嘗試重傳。由于存在網絡 2 將軍問題，即當 order-service 發送給消息中間件的消息網絡超時時，這時候消息中間件可能收到了消息但響應 ACK 失敗，也可能沒收到，order-service 會再次發送該消息，直至消息中間件響應 ACK 成功，這樣可能發生消息的重復發送，不過沒關系，只要保證消息不丟失，不亂序就行，后面 repo-service 會做去重處理。

3）消息中間件向 repo-service 推送 repo_deduction_msg，repo-service 成功處理完成后會向中間件響應 ACK，消息中間件收到這個 ACK 才認為 repo-service 成功處理了這條消息，否則會重復推送該消息。但是有這樣的情形：repo-service 成功處理了消息，向中間件發送的 ACK 在網絡傳輸中由于網絡故障丟失了，導致中間件沒有收到 ACK 重新推送了該消息。這也要靠 repo-service 的消息去重特性來避免消息重復消費。

4）在 2）和 3）中提到了兩種導致 repo-service 重復收到消息的原因，一是生產者重復生產，二是中間件重傳。為了實現業務的冪等性，repo-service 中維護了一張判重表，這張表中記錄了被成功處理的消息的 id。repo-service 每次接收到新的消息都先判斷消息是否被成功處理過，若是的話不再重復處理。

通過這種設計，實現了消息在發送方不丟失，消息在接收方不被重復消費，聯合起來就是消息不漏不重，嚴格實現了 order-service 和 repo-service 的兩個數據庫中數據的最終一致性。

基于消息中間件的最終一致性全局事務方案是互聯網公司在高并發場景中探索出的一種創新型應用模式，利用 MQ 實現微服務之間的異步調用、解耦合和流量削峰，支持全局事務的高并發，并保證分布式數據記錄的最終一致性。

3. Seata in AT mode 的實現

第 2 章給出了實現實現分布式事務的集中常見的理論模型。本章給出業界開源分布式事務框架 Seata 的實現。

Seata 為用戶提供了 AT、TCC、SAGA 和 XA 事務模式。其中 AT 模式是 Seata 主推的事務模式，因此本章分析 Seata in AT mode 的實現。使用 AT 有一個前提，那就是微服務使用的數據庫必須是支持事務的關系型數據庫。

3.1. Seata in AT mode 工作流程概述

Seata 的 AT 模式建立在關系型數據庫的本地事務特性的基礎之上，通過數據源代理類攔截并解析數據庫執行的 SQL，記錄自定義的回滾日志，如需回滾，則重放這些自定義的回滾日志即可。AT 模式雖然是根據 XA 事務模型（2PC）演進而來的，但是 AT 打破了 XA 協議的阻塞性制約，在一致性和性能上取得了平衡。

AT 模式是基于 XA 事務模型演進而來的，它的整體機制也是一個改進版本的兩階段提交協議。AT 模式的兩個基本階段是：

1）第一階段：首先獲取本地鎖，執行本地事務，業務數據操作和記錄回滾日志在同一個本地事務中提交，最后釋放本地鎖；

2）第二階段：如需全局提交，異步刪除回滾日志即可，這個過程很快就能完成。如需要回滾，則通過第一階段的回滾日志進行反向補償。

本章描述 Seata in AT mode 的工作原理使用的電商微服務模型如下圖所示：

在上圖中，協調者 shopping-service 先調用參與者 repo-service 扣減庫存，后調用參與者 order-service 生成訂單。這個業務流使用 Seata in XA mode 后的全局事務流程如下圖所示：

上圖描述的全局事務執行流程為：

1）shopping-service 向 Seata 注冊全局事務，并產生一個全局事務標識 XID

2）將 repo-service.repo_db、order-service.order_db 的本地事務執行到待提交階段，事務內容包含對 repo-service.repo_db、order-service.order_db 進行的查詢操作以及寫每個庫的 undo_log 記錄

3）repo-service.repo_db、order-service.order_db 向 Seata 注冊分支事務，并將其納入該 XID 對應的全局事務范圍

4）提交 repo-service.repo_db、order-service.order_db 的本地事務

5）repo-service.repo_db、order-service.order_db 向 Seata 匯報分支事務的提交狀態

6）Seata 匯總所有的 DB 的分支事務的提交狀態，決定全局事務是該提交還是回滾

7）Seata 通知 repo-service.repo_db、order-service.order_db 提交/回滾本地事務，若需要回滾，采取的是補償式方法

其中 1）2）3）4）5）屬于第一階段，6）7）屬于第二階段。

3.2. Seata in AT mode 工作流程詳述

在上面的電商業務場景中，購物服務調用庫存服務扣減庫存，調用訂單服務創建訂單，顯然這兩個調用過程要放在一個事務里面。即：

start?global_trx

?call?庫存服務的扣減庫存接口

?call?訂單服務的創建訂單接口

commit?global_trx

在庫存服務的數據庫中，存在如下的庫存表 t_repo：

在訂單服務的數據庫中，存在如下的訂單表 t_order：

現在，id 為 40002 的用戶要購買一只商品代碼為 20002 的鼠標，整個分布式事務的內容為：

1）在庫存服務的庫存表中將記錄

修改為

2）在訂單服務的訂單表中添加一條記錄

以上操作，在 AT 模式的第一階段的流程圖如下：

從 AT 模式第一階段的流程來看，分支的本地事務在第一階段提交完成之后，就會釋放掉本地事務鎖定的本地記錄。這是 AT 模式和 XA 最大的不同點，在 XA 事務的兩階段提交中，被鎖定的記錄直到第二階段結束才會被釋放。所以 AT 模式減少了鎖記錄的時間，從而提高了分布式事務的處理效率。AT 模式之所以能夠實現第一階段完成就釋放被鎖定的記錄，是因為 Seata 在每個服務的數據庫中維護了一張 undo_log 表，其中記錄了對 t_order / t_repo 進行操作前后記錄的鏡像數據，即便第二階段發生異常，只需回放每個服務的 undo_log 中的相應記錄即可實現全局回滾。

undo_log 的表結構：

第一階段結束之后，Seata 會接收到所有分支事務的提交狀態，然后決定是提交全局事務還是回滾全局事務。

1）若所有分支事務本地提交均成功，則 Seata 決定全局提交。Seata 將分支提交的消息發送給各個分支事務，各個分支事務收到分支提交消息后，會將消息放入一個緩沖隊列，然后直接向 Seata 返回提交成功。之后，每個本地事務會慢慢處理分支提交消息，處理的方式為：刪除相應分支事務的 undo_log 記錄。之所以只需刪除分支事務的 undo_log 記錄，而不需要再做其他提交操作，是因為提交操作已經在第一階段完成了（這也是 AT 和 XA 不同的地方）。這個過程如下圖所示：

分支事務之所以能夠直接返回成功給 Seata，是因為真正關鍵的提交操作在第一階段已經完成了，清除 undo_log 日志只是收尾工作，即便清除失敗了，也對整個分布式事務不產生實質影響。

2）若任一分支事務本地提交失敗，則 Seata 決定全局回滾，將分支事務回滾消息發送給各個分支事務，由于在第一階段各個服務的數據庫上記錄了 undo_log 記錄，分支事務回滾操作只需根據 undo_log 記錄進行補償即可。全局事務的回滾流程如下圖所示：

這里對圖中的 2、3 步做進一步的說明：

1）由于上文給出了 undo_log 的表結構，所以可以通過 xid 和 branch_id 來找到當前分支事務的所有 undo_log 記錄；

2）拿到當前分支事務的 undo_log 記錄之后，首先要做數據校驗，如果 afterImage 中的記錄與當前的表記錄不一致，說明從第一階段完成到此刻期間，有別的事務修改了這些記錄，這會導致分支事務無法回滾，向 Seata 反饋回滾失??；如果 afterImage 中的記錄與當前的表記錄一致，說明從第一階段完成到此刻期間，沒有別的事務修改這些記錄，分支事務可回滾，進而根據 beforeImage 和 afterImage 計算出補償 SQL，執行補償 SQL 進行回滾，然后刪除相應 undo_log，向 Seata 反饋回滾成功。

事務具有 ACID 特性，全局事務解決方案也在盡量實現這四個特性。以上關于 Seata in AT mode 的描述很顯然體現出了 AT 的原子性、一致性和持久性。下面著重描述一下 AT 如何保證多個全局事務的隔離性的。

在 AT 中，當多個全局事務操作同一張表時，通過全局鎖來保證事務的隔離性。下面描述一下全局鎖在讀隔離和寫隔離兩個場景中的作用原理：

1）寫隔離（若有全局事務在改/寫/刪記錄，另一個全局事務對同一記錄進行的改/寫/刪要被隔離起來，即寫寫互斥）：寫隔離是為了在多個全局事務對同一張表的同一個字段進行更新操作時，避免一個全局事務在沒有被提交成功之前所涉及的數據被其他全局事務修改。寫隔離的基本原理是：在第一階段本地事務（開啟本地事務的時候，本地事務會對涉及到的記錄加本地鎖）提交之前，確保拿到全局鎖。如果拿不到全局鎖，就不能提交本地事務，并且不斷嘗試獲取全局鎖，直至超出重試次數，放棄獲取全局鎖，回滾本地事務，釋放本地事務對記錄加的本地鎖。

假設有兩個全局事務 gtrx_1 和 gtrx_2 在并發操作庫存服務，意圖扣減如下記錄的庫存數量：

AT 實現寫隔離過程的時序圖如下：

圖中，1、2、3、4 屬于第一階段，5 屬于第二階段。

在上圖中 gtrx_1 和 gtrx_2 均成功提交，如果 gtrx_1 在第二階段執行回滾操作，那么 gtrx_1 需要重新發起本地事務獲取本地鎖，然后根據 undo_log 對這個 id=10002 的記錄進行補償式回滾。此時 gtrx_2 仍在等待全局鎖，且持有這個 id=10002 的記錄的本地鎖，因此 gtrx_1 會回滾失?。╣trx_1 回滾需要同時持有全局鎖和對 id=10002 的記錄加的本地鎖），回滾失敗的 gtrx_1 會一直重試回滾。直到旁邊的 gtrx_2 獲取全局鎖的嘗試次數超過閾值，gtrx_2 會放棄獲取全局鎖，發起本地回滾，本地回滾結束后，自然會釋放掉對這個 id=10002 的記錄加的本地鎖。此時，gtrx_1 終于可以成功對這個 id=10002 的記錄加上了本地鎖，同時拿到了本地鎖和全局鎖的 gtrx_1 就可以成功回滾了。整個過程，全局鎖始終在 gtrx_1 手中，并不會發生臟寫的問題。整個過程的流程圖如下所示：

2）讀隔離（若有全局事務在改/寫/刪記錄，另一個全局事務對同一記錄的讀取要被隔離起來，即讀寫互斥）：在數據庫本地事務的隔離級別為讀已提交、可重復讀、串行化時（讀未提交不起什么隔離作用，一般不使用），Seata AT 全局事務模型產生的隔離級別是讀未提交，也就是說一個全局事務會看到另一個全局事務未全局提交的數據，產生臟讀，從前文的第一階段和第二階段的流程圖中也可以看出這一點。這在最終一致性的分布式事務模型中是可以接受的。

如果要求 AT 模型一定要實現讀已提交的事務隔離級別，可以利用 Seata 的 SelectForUpdateExecutor 執行器對 SELECT FOR UPDATE 語句進行代理。SELECT FOR UPDATE 語句在執行時會申請全局鎖，如果全局鎖已經被其他全局事務占有，則回滾 SELECT FOR UPDATE 語句的執行，釋放本地鎖，并且重試 SELECT FOR UPDATE 語句。在這個過程中，查詢請求會被阻塞，直到拿到全局鎖（也就是要讀取的記錄被其他全局事務提交），讀到已被全局事務提交的數據才返回。這個過程如下圖所示：

4. 結束語

XA 協議是 X/Open 提出的分布式事務處理標準。文中提到的 2PC、3PC、TCC、本地事務表、Seata in AT mode，無論哪一種，本質都是事務協調者協調各個事務參與者的本地事務的進度，使使所有本地事務共同提交或回滾，最終達成一種全局的 ACID 特性。在協調的過程中，協調者需要收集各個本地事務的當前狀態，并根據這些狀態發出下一階段的操作指令。這個思想就是 XA 協議的要義，我們可以說這些事務模型遵守或大致遵守了 XA 協議。

基于消息中間件的最終一致性事務方案是互聯網公司在高并發場景中探索出的一種創新型應用模式，利用 MQ 實現微服務之間的異步調用、解耦合和流量削峰，保證分布式數據記錄的最終一致性。它顯然不遵守 XA 協議。

對于某項技術，可能存在業界標準或協議，但實踐者針對具體應用場景的需求或者出于簡便的考慮，給出與標準不完全相符的實現，甚至完全不相符的實現，這在工程領域是一種常見的現象。TCC 方案如此、基于消息中間件的最終一致性事務方案如此、Seata in AT mode 模式也如此。而新的標準往往就在這些創新中產生。

。

。

。

。

你難道真的沒有發現 2.6 節（基于消息中間件的最終一致性事務方案）給出的正確方案中存在的業務漏洞嗎？請各位重新看下這張圖，仔細品一品兩個微服務的調用方向，把你的想法留在評論區吧 :-)

特別推薦一個分享架構+算法的優質內容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝