1-4 w 字，25 張圖讓你徹底掌握分佈式事務原理

• 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. 前言

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. 二將軍問題和冪等性

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

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

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

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

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 通信）放在本地數據庫事務裏，可能會因爲網絡延遲產生數據庫長事務，影響數據庫本地事務的併發度。

015

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

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

1）order-service 中，

1在 t_order 表添加訂單記錄 &&
2
3在 t_local_msg 添加對應的扣減庫存消息
4
5
6

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

 1檢查本次扣庫存操作是否已經執行過 &&
 2
 3執行扣減庫存如果本次扣減操作沒有執行過 &&
 4
 5寫判重表 &&
 6
 7向 MQ sever 反饋消息消費完成 ACK
 8
 9
10

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

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 工作流程詳述

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

 1start global_trx
 2
 3 call 庫存服務的扣減庫存接口
 4
 5 call 訂單服務的創建訂單接口
 6
 7commit global_trx
 8
 9
10

在庫存服務的數據庫中，存在如下的庫存表 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 會回滾失敗（gtrx_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 節（基於消息中間件的最終一致性事務方案）給出的正確方案中存在的業務漏洞嗎？請各位重新看下這張圖，仔細品一品兩個微服務的調用方向，把你的想法留在評論區吧 :-)

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4AYMb_v3GctPddpKUZUUfw