14K 字，25 張圖徹底掌握分布式事務原理！
本文提綱如下
0. 前言
1. 單數(shù)據(jù)源事務 & 多數(shù)據(jù)源事務
2. 常見分布式事務解決方案
2.1. 分布式事務模型
2.2. 二將軍問題和冪等性
2.3. 兩階段提交（2PC） & 三階段提交（3PC）方案
2.4. TCC 方案
2.5. 事務狀態(tài)表方案
2.6. 基于消息中間件的最終一致性事務方案
3. Seata in AT mode 的實現(xiàn)
3.1. Seata in AT mode 工作流程概述
3.2. Seata in AT mode 工作流程詳述
4. 結(jié)束語
0. 前言
從 CPU 到內(nèi)存、到磁盤、到操作系統(tǒng)、到網(wǎng)絡，計算機系統(tǒng)處處存在不可靠因素。工程師和科學家努力使用各種軟硬件方法對抗這種不可靠因素，保證數(shù)據(jù)和指令被正確地處理。在網(wǎng)絡領域有 TCP 可靠傳輸協(xié)議、在存儲領域有 Raid5 和 Raid6 算法、在數(shù)據(jù)庫領域有基于 ARIES 算法理論實現(xiàn)的事務機制……
這篇文章先介紹單機數(shù)據(jù)庫事務的 ACID 特性，然后指出分布式場景下操作多數(shù)據(jù)源面臨的困境，引出分布式系統(tǒng)中常用的分布式事務解決方案，這些解決方案可以保證業(yè)務代碼在操作多個數(shù)據(jù)源的時候，能夠像操作單個數(shù)據(jù)源一樣，具備 ACID 特性。文章在最后給出業(yè)界較為成熟的分布式事務框架——Seata 的 AT 模式全局事務的實現(xiàn)。
1. 單數(shù)據(jù)源事務 & 多數(shù)據(jù)源事務
如果一個應用程序在一次業(yè)務流中通過連接驅(qū)動和數(shù)據(jù)源接口只連接并查詢（這里的查詢是廣義的，包括增刪查改等）一個特定的數(shù)據(jù)庫，該應用程序就可以利用數(shù)據(jù)庫提供的事務機制（如果數(shù)據(jù)庫支持事務的話）保證對庫中記錄所進行的操作的可靠性，這里的可靠性有四種語義：
- 原子性，A
- 一致性，C
- 隔離性，I
- 持久性，D
筆者在這里不再對這四種語義進行解釋，了解單數(shù)據(jù)源事務及其 ACID 特性是讀者閱讀這篇文章的前提。單個數(shù)據(jù)庫實現(xiàn)自身的事務特性是一個復雜又微妙的過程，例如 MySQL 的 InnoDB 引擎通過 Undo Log + Redo Log + ARIES 算法來實現(xiàn)。這是一個很宏大的話題，不在本文的描述范圍，讀者有興趣的話可自行研究。
單數(shù)據(jù)源事務也可以叫做單機事務，或者本地事務。
在分布式場景下，一個系統(tǒng)由多個子系統(tǒng)構(gòu)成，每個子系統(tǒng)有獨立的數(shù)據(jù)源。多個子系統(tǒng)之間通過互相調(diào)用來組合出更復雜的業(yè)務。在時下流行的微服務系統(tǒng)架構(gòu)中，每一個子系統(tǒng)被稱作一個微服務，同樣每個微服務都維護自己的數(shù)據(jù)庫，以保持獨立性。
例如，一個電商系統(tǒng)可能由購物微服務、庫存微服務、訂單微服務等組成。購物微服務通過調(diào)用庫存微服務和訂單微服務來整合出購物業(yè)務。用戶請求購物微服務商完成下單時，購物微服務一方面調(diào)用庫存微服務扣減相應商品的庫存數(shù)量，另一方面調(diào)用訂單微服務插入訂單記錄（為了后文描述分布式事務解決方案的方便，這里給出的是一個最簡單的電商系統(tǒng)微服務劃分和最簡單的購物業(yè)務流程，后續(xù)的支付、物流等業(yè)務不在考慮范圍內(nèi)）。電商系統(tǒng)模型如下圖所示：
在用戶購物的業(yè)務場景中，shopping-service 的業(yè)務涉及兩個數(shù)據(jù)庫：庫存庫（repo_db）和訂單庫（repo_db），也就是 g 購物業(yè)務是調(diào)用多數(shù)據(jù)源來組合而成的。作為一個面向消費者的系統(tǒng)，電商系統(tǒng)要保證購物業(yè)務的高度可靠性，這里的可靠性同樣有 ACID 四種語義。
但是一個數(shù)據(jù)庫的本地事務機制僅僅對落到自己身上的查詢操作（這里的查詢是廣義的，包括增刪改查等）起作用，無法干涉對其他數(shù)據(jù)庫的查詢操作。所以，數(shù)據(jù)庫自身提供的本地事務機制無法確保業(yè)務對多數(shù)據(jù)源全局操作的可靠性。
基于此，針對多數(shù)據(jù)源操作提出的分布式事務機制就出現(xiàn)了。
分布式事務也可以叫做全局事務。
2. 常見分布式事務解決方案
2.1. 分布式事務模型
描述分布式事務，常常會使用以下幾個名詞：
- 事務參與者：例如每個數(shù)據(jù)庫就是一個事務參與者
- 事務協(xié)調(diào)者：訪問多個數(shù)據(jù)源的服務程序，例如 shopping-service 就是事務協(xié)調(diào)者
- 資源管理器（Resource Manager, RM）：通常與事務參與者同義
- 事務管理器（Transaction Manager, TM）：通常與事務協(xié)調(diào)者同義
在分布式事務模型中，一個 TM 管理多個 RM，即一個服務程序訪問多個數(shù)據(jù)源；TM 是一個全局事務管理器，協(xié)調(diào)多方本地事務的進度，使其共同提交或回滾，最終達成一種全局的 ACID 特性。
2.2. 二將軍問題和冪等性
二將軍問題是網(wǎng)絡領域的一個經(jīng)典問題，用于表達計算機網(wǎng)絡中互聯(lián)協(xié)議設計的微妙性和復雜性。這里給出一個二將軍問題的簡化版本：
一支白軍被圍困在一個山谷中，山谷的左右兩側(cè)是藍軍。困在山谷中的白軍人數(shù)多于山谷兩側(cè)的任意一支藍軍，而少于兩支藍軍的之和。若一支藍軍對白軍單獨發(fā)起進攻，則必敗無疑；但若兩支藍軍同時發(fā)起進攻，則可取勝。兩只藍軍的總指揮位于山谷左側(cè)，他希望兩支藍軍同時發(fā)起進攻，這樣就要把命令傳到山谷右側(cè)的藍軍，以告知發(fā)起進攻的具體時間。假設他們只能派遣士兵穿越白軍所在的山谷（唯一的通信信道）來傳遞消息，那么在穿越山谷時，士兵有可能被俘虜。
只有當送信士兵成功往返后，總指揮才能確認這場戰(zhàn)爭的勝利（上方圖）。現(xiàn)在問題來了，派遣出去送信的士兵沒有回來，則左側(cè)藍軍中的總指揮能不能決定按命令中約定的時間發(fā)起進攻？
答案是不確定，派遣出去送信的士兵沒有回來，他可能遇到兩種狀況：
1）命令還沒送達就被俘虜了（中間圖），這時候右側(cè)藍軍根本不知道要何時進攻；
2）命令送達，但返回途中被俘虜了（下方圖），這時候右側(cè)藍軍知道要何時進攻，但左側(cè)藍軍不知道右側(cè)藍軍是否知曉進攻時間。
類似的問題在計算機網(wǎng)絡中普遍存在，例如發(fā)送者給接受者發(fā)送一個 HTTP 請求，或者 MySQL 客戶端向 MySQL 服務器發(fā)送一條插入語句，然后超時了沒有得到響應。請問服務器是寫入成功了還是失敗了？答案是不確定，有以下幾種情況：
1）可能請求由于網(wǎng)絡故障根本沒有送到服務器，因此寫入失敗；
2）可能服務器收到了，也寫入成功了，但是向客戶端發(fā)送響應前服務器宕機了；
3）可能服務器收到了，也寫入成功了，也向客戶端發(fā)送了響應，但是由于網(wǎng)絡故障未送到客戶端。
無論哪種場景，在客戶端看來都是一樣的結(jié)果：它發(fā)出的請求沒有得到響應。為了確保服務端成功寫入數(shù)據(jù)，客戶端只能重發(fā)請求，直至接收到服務端的響應。
類似的問題問題被稱為網(wǎng)絡二將軍問題。
網(wǎng)絡二將軍問題的存在使得消息的發(fā)送者往往要重復發(fā)送消息，直到收到接收者的確認才認為發(fā)送成功，但這往往又會導致消息的重復發(fā)送。例如電商系統(tǒng)中訂單模塊調(diào)用支付模塊扣款的時候，如果網(wǎng)絡故障導致二將軍問題出現(xiàn)，扣款請求重復發(fā)送，產(chǎn)生的重復扣款結(jié)果顯然是不能被接受的。因此要保證一次事務中的扣款請求無論被發(fā)送多少次，接收方有且只執(zhí)行一次扣款動作，這種保證機制叫做接收方的冪等性。
2.3. 兩階段提交（2PC） & 三階段提交（3PC）方案
2PC 是一種實現(xiàn)分布式事務的簡單模型，這兩個階段是：
1）準備階段：事務協(xié)調(diào)者向各個事務參與者發(fā)起詢問請求：“我要執(zhí)行全局事務了，這個事務涉及到的資源分布在你們這些數(shù)據(jù)源中，分別是……，你們準備好各自的資源（即各自執(zhí)行本地事務到待提交階段）”。各個參與者協(xié)調(diào)者回復 yes（表示已準備好，允許提交全局事務）或 no（表示本參與者無法拿到全局事務所需的本地資源，因為它被其他本地事務鎖住了）或超時。
2）提交階段：如果各個參與者回復的都是 yes，則協(xié)調(diào)者向所有參與者發(fā)起事務提交操作，然后所有參與者收到后各自執(zhí)行本地事務提交操作并向協(xié)調(diào)者發(fā)送 ACK；如果任何一個參與者回復 no 或者超時，則協(xié)調(diào)者向所有參與者發(fā)起事務回滾操作，然后所有參與者收到后各自執(zhí)行本地事務回滾操作并向協(xié)調(diào)者發(fā)送 ACK。
2PC 的流程如下圖所示：
從上圖可以看出，要實現(xiàn) 2PC，所有的參與者都要實現(xiàn)三個接口：
Prepare()：TM 調(diào)用該接口詢問各個本地事務是否就緒
Commit()：TM 調(diào)用該接口要求各個本地事務提交
Rollback()：TM 調(diào)用該接口要求各個本地事務回滾
可以將這三個接口簡單地（但不嚴謹?shù)兀├斫獬?XA 協(xié)議。XA 協(xié)議是 X/Open 提出的分布式事務處理標準。MySQL、Oracle、DB2 這些主流數(shù)據(jù)庫都實現(xiàn)了 XA 協(xié)議，因此都能被用于實現(xiàn) 2PC 事務模型。
2PC 簡明易懂，但存在如下的問題：
1）性能差，在準備階段，要等待所有的參與者返回，才能進入階段二，在這期間，各個參與者上面的相關資源被排他地鎖住，參與者上面意圖使用這些資源的本地事務只能等待。因為存在這種同步阻塞問題，所以影響了各個參與者的本地事務并發(fā)度；
2）準備階段完成后，如果協(xié)調(diào)者宕機，所有的參與者都收不到提交或回滾指令，導致所有參與者“不知所措”；
3）在提交階段，協(xié)調(diào)者向所有的參與者發(fā)送了提交指令，如果一個參與者未返回 ACK，那么協(xié)調(diào)者不知道這個參與者內(nèi)部發(fā)生了什么（由于網(wǎng)絡二將軍問題的存在，這個參與者可能根本沒收到提交指令，一直處于等待接收提交指令的狀態(tài)；也可能收到了，并成功執(zhí)行了本地提交，但返回的 ACK 由于網(wǎng)絡故障未送到協(xié)調(diào)者上），也就無法決定下一步是否進行全體參與者的回滾。
2PC 之后又出現(xiàn)了 3PC，把兩階段過程變成了三階段過程，分別是：詢問階段、準備階段、提交或回滾階段，這里不再詳述。3PC 利用超時機制解決了 2PC 的同步阻塞問題，避免資源被永久鎖定，進一步加強了整個事務過程的可靠性。但是 3PC 同樣無法應對類似的宕機問題，只不過出現(xiàn)多數(shù)據(jù)源中數(shù)據(jù)不一致問題的概率更小。
2PC 除了性能和可靠性上存在問題，它的適用場景也很局限，它要求參與者實現(xiàn)了 XA 協(xié)議，例如使用實現(xiàn)了 XA 協(xié)議的數(shù)據(jù)庫作為參與者可以完成 2PC 過程。但是在多個系統(tǒng)服務利用 api 接口相互調(diào)用的時候，就不遵守 XA 協(xié)議了，這時候 2PC 就不適用了。所以 2PC 在分布式應用場景中很少使用。
所以前文提到的電商場景無法使用 2PC，因為 shopping-service 通過 RPC 接口或者 Rest 接口調(diào)用 repo-service 和 order-service 間接訪問 repo_db 和 order_db。除非 shopping-service 直接配置 repo_db 和 order_db 作為自己的數(shù)據(jù)庫。
2.4. TCC 方案
描述 TCC 方案使用的電商微服務模型如下圖所示，在這個模型中，shopping-service 是事務協(xié)調(diào)者，repo-service 和 order-service 是事務參與者。
上文提到，2PC 要求參與者實現(xiàn)了 XA 協(xié)議，通常用來解決多個數(shù)據(jù)庫之間的事務問題，比較局限。在多個系統(tǒng)服務利用 api 接口相互調(diào)用的時候，就不遵守 XA 協(xié)議了，這時候 2PC 就不適用了。現(xiàn)代企業(yè)多采用分布式的微服務，因此更多的是要解決多個微服務之間的分布式事務問題。
TCC 就是一種解決多個微服務之間的分布式事務問題的方案。TCC 是 Try、Confirm、Cancel 三個詞的縮寫，其本質(zhì)是一個應用層面上的 2PC，同樣分為兩個階段：
1）階段一：準備階段。協(xié)調(diào)者調(diào)用所有的每個微服務提供的 try 接口，將整個全局事務涉及到的資源鎖定住，若鎖定成功 try 接口向協(xié)調(diào)者返回 yes。
2）階段二：提交階段。若所有的服務的 try 接口在階段一都返回 yes，則進入提交階段，協(xié)調(diào)者調(diào)用所有服務的 confirm 接口，各個服務進行事務提交。如果有任何一個服務的 try 接口在階段一返回 no 或者超時，則協(xié)調(diào)者調(diào)用所有服務的 cancel 接口。
TCC 的流程如下圖所示：
這里有個關鍵問題，既然 TCC 是一種服務層面上的 2PC，它是如何解決 2PC 無法應對宕機問題的缺陷的呢？答案是不斷重試。由于 try 操作鎖住了全局事務涉及的所有資源，保證了業(yè)務操作的所有前置條件得到滿足，因此無論是 confirm 階段失敗還是 cancel 階段失敗都能通過不斷重試直至 confirm 或 cancel 成功（所謂成功就是所有的服務都對 confirm 或者 cancel 返回了 ACK）。
這里還有個關鍵問題，在不斷重試 confirm 和 cancel 的過程中（考慮到網(wǎng)絡二將軍問題的存在）有可能重復進行了 confirm 或 cancel，因此還要再保證 confirm 和 cancel 操作具有冪等性，也就是整個全局事務中，每個參與者只進行一次 confirm 或者 cancel。實現(xiàn) confirm 和 cancel 操作的冪等性，有很多解決方案，例如每個參與者可以維護一個去重表（可以利用數(shù)據(jù)庫表實現(xiàn)也可以使用內(nèi)存型 KV 組件實現(xiàn)），記錄每個全局事務（以全局事務標記 XID 區(qū)分）是否進行過 confirm 或 cancel 操作，若已經(jīng)進行過，則不再重復執(zhí)行。
TCC 由支付寶團隊提出，被廣泛應用于金融系統(tǒng)中。我們用銀行賬戶余額購買基金時，會注意到銀行賬戶中用于購買基金的那部分余額首先會被凍結(jié)，由此我們可以猜想，這個過程大概就是 TCC 的第一階段。
2.5. 事務狀態(tài)表方案
另外有一種類似 TCC 的事務解決方案，借助事務狀態(tài)表來實現(xiàn)。假設要在一個分布式事務中實現(xiàn)調(diào)用 repo-service 扣減庫存、調(diào)用 order-service 生成訂單兩個過程。在這種方案中，協(xié)調(diào)者 shopping-service 維護一張如下的事務狀態(tài)表：
| 分布式事務 ID | 事務內(nèi)容 | 事務狀態(tài) |
|---|---|---|
| global_trx_id_1 | 操作 1：調(diào)用 repo-service 扣減庫存 操作 2：調(diào)用 order-service 生成訂單 | 狀態(tài) 1：初始 狀態(tài) 2：操作 1 成功 狀態(tài) 3：操作 1、2 成功 |
初始狀態(tài)為 1，每成功調(diào)用一個服務則更新一次狀態(tài)，最后所有的服務調(diào)用成功，狀態(tài)更新到 3。
有了這張表，就可以啟動一個后臺任務，掃描這張表中事務的狀態(tài)，如果一個分布式事務一直（設置一個事務周期閾值）未到狀態(tài) 3，說明這條事務沒有成功執(zhí)行，于是可以重新調(diào)用 repo-service 扣減庫存、調(diào)用 order-service 生成訂單。直至所有的調(diào)用成功，事務狀態(tài)到 3。
如果多次重試仍未使得狀態(tài)到 3，可以將事務狀態(tài)置為 error，通過人工介入進行干預。
由于存在服務的調(diào)用重試，因此每個服務的接口要根據(jù)全局的分布式事務 ID 做冪等，原理同 2.4 節(jié)的冪等性實現(xiàn)。
2.6. 基于消息中間件的最終一致性事務方案
無論是 2PC & 3PC 還是 TCC、事務狀態(tài)表，基本都遵守 XA 協(xié)議的思想，即這些方案本質(zhì)上都是事務協(xié)調(diào)者協(xié)調(diào)各個事務參與者的本地事務的進度，使所有本地事務共同提交或回滾，最終達成一種全局的 ACID 特性。在協(xié)調(diào)的過程中，協(xié)調(diào)者需要收集各個本地事務的當前狀態(tài)，并根據(jù)這些狀態(tài)發(fā)出下一階段的操作指令。
但是這些全局事務方案由于操作繁瑣、時間跨度大，或者在全局事務期間會排他地鎖住相關資源，使得整個分布式系統(tǒng)的全局事務的并發(fā)度不會太高。這很難滿足電商等高并發(fā)場景對事務吞吐量的要求，因此互聯(lián)網(wǎng)服務提供商探索出了很多與 XA 協(xié)議背道而馳的分布式事務解決方案。其中利用消息中間件實現(xiàn)的最終一致性全局事務就是一個經(jīng)典方案。
為了表現(xiàn)出這種方案的精髓，我將使用如下的電商系統(tǒng)微服務結(jié)構(gòu)來進行描述：
在這個模型中，用戶不再是請求整合后的 shopping-service 進行下單，而是直接請求 order-service 下單，order-service 一方面添加訂單記錄，另一方面會調(diào)用 repo-service 扣減庫存。
這種基于消息中間件的最終一致性事務方案常常被誤解成如下的實現(xiàn)方式：
這種實現(xiàn)方式的流程是：
1）order-service 負責向 MQ server 發(fā)送扣減庫存消息（repo_deduction_msg）；repo-service 訂閱 MQ server 中的扣減庫存消息，負責消費消息。
2）用戶下單后，order-service 先執(zhí)行插入訂單記錄的查詢語句，后將 repo_deduction_msg 發(fā)到消息中間件中，這兩個過程放在一個本地事務中進行，一旦“執(zhí)行插入訂單記錄的查詢語句”失敗，導致事務回滾，“將 repo_deduction_msg 發(fā)到消息中間件中”就不會發(fā)生；同樣，一旦“將 repo_deduction_msg 發(fā)到消息中間件中”失敗，拋出異常，也會導致“執(zhí)行插入訂單記錄的查詢語句”操作回滾，最終什么也沒有發(fā)生。
3）repo-service 接收到 repo_deduction_msg 之后，先執(zhí)行庫存扣減查詢語句，后向 MQ sever 反饋消息消費完成 ACK，這兩個過程放在一個本地事務中進行，一旦“執(zhí)行庫存扣減查詢語句”失敗，導致事務回滾，“向 MQ sever 反饋消息消費完成 ACK”就不會發(fā)生，MQ server 在 Confirm 機制的驅(qū)動下會繼續(xù)向 repo-service 推送該消息，直到整個事務成功提交；同樣，一旦“向 MQ sever 反饋消息消費完成 ACK”失敗，拋出異常，也對導致“執(zhí)行庫存扣減查詢語句”操作回滾，MQ server 在 Confirm 機制的驅(qū)動下會繼續(xù)向 repo-service 推送該消息，直到整個事務成功提交。
這種做法看似很可靠。但沒有考慮到網(wǎng)絡二將軍問題的存在，有如下的缺陷：
1）存在網(wǎng)絡的 2 將軍問題，上面第 2）步中 order-service 發(fā)送 repo_deduction_msg 消息失敗，對于發(fā)送方 order-service 來說，可能是消息中間件沒有收到消息；也可能是中間件收到了消息，但向發(fā)送方 order-service 響應的 ACK 由于網(wǎng)絡故障沒有被 order-service 收到。因此 order-service 貿(mào)然進行事務回滾，撤銷“執(zhí)行插入訂單記錄的查詢語句”，是不對的，因為 repo-service 那邊可能已經(jīng)接收到 repo_deduction_msg 并成功進行了庫存扣減，這樣 order-service 和 repo-service 兩方就產(chǎn)生了數(shù)據(jù)不一致問題。
2）repo-service 和 order-service 把網(wǎng)絡調(diào)用（與 MQ server 通信）放在本地數(shù)據(jù)庫事務里，可能會因為網(wǎng)絡延遲產(chǎn)生數(shù)據(jù)庫長事務，影響數(shù)據(jù)庫本地事務的并發(fā)度。
以上是被誤解的實現(xiàn)方式，下面給出正確的實現(xiàn)方式，如下所示：
上圖所示的方案，利用消息中間件如 rabbitMQ 來實現(xiàn)分布式下單及庫存扣減過程的最終一致性。對這幅圖做以下說明：
1）order-service 中，
在 t_order 表添加訂單記錄 &&
在 t_local_msg 添加對應的扣減庫存消息
這兩個過程要在一個事務中完成，保證過程的原子性。同樣，repo-service 中，
檢查本次扣庫存操作是否已經(jīng)執(zhí)行過 &&
執(zhí)行扣減庫存如果本次扣減操作沒有執(zhí)行過 &&
寫判重表 &&
向 MQ sever 反饋消息消費完成 ACK
這四個過程也要在一個事務中完成，保證過程的原子性。
2）order-service 中有一個后臺程序，源源不斷地把消息表中的消息傳送給消息中間件，成功后則刪除消息表中對應的消息。如果失敗了，也會不斷嘗試重傳。由于存在網(wǎng)絡 2 將軍問題，即當 order-service 發(fā)送給消息中間件的消息網(wǎng)絡超時時，這時候消息中間件可能收到了消息但響應 ACK 失敗，也可能沒收到，order-service 會再次發(fā)送該消息，直至消息中間件響應 ACK 成功，這樣可能發(fā)生消息的重復發(fā)送，不過沒關系，只要保證消息不丟失，不亂序就行，后面 repo-service 會做去重處理。
3）消息中間件向 repo-service 推送 repo_deduction_msg，repo-service 成功處理完成后會向中間件響應 ACK，消息中間件收到這個 ACK 才認為 repo-service 成功處理了這條消息，否則會重復推送該消息。但是有這樣的情形：repo-service 成功處理了消息，向中間件發(fā)送的 ACK 在網(wǎng)絡傳輸中由于網(wǎng)絡故障丟失了，導致中間件沒有收到 ACK 重新推送了該消息。這也要靠 repo-service 的消息去重特性來避免消息重復消費。
4）在 2）和 3）中提到了兩種導致 repo-service 重復收到消息的原因，一是生產(chǎn)者重復生產(chǎn)，二是中間件重傳。為了實現(xiàn)業(yè)務的冪等性，repo-service 中維護了一張判重表，這張表中記錄了被成功處理的消息的 id。repo-service 每次接收到新的消息都先判斷消息是否被成功處理過，若是的話不再重復處理。
通過這種設計，實現(xiàn)了消息在發(fā)送方不丟失，消息在接收方不被重復消費，聯(lián)合起來就是消息不漏不重，嚴格實現(xiàn)了 order-service 和 repo-service 的兩個數(shù)據(jù)庫中數(shù)據(jù)的最終一致性。
基于消息中間件的最終一致性全局事務方案是互聯(lián)網(wǎng)公司在高并發(fā)場景中探索出的一種創(chuàng)新型應用模式，利用 MQ 實現(xiàn)微服務之間的異步調(diào)用、解耦合和流量削峰，支持全局事務的高并發(fā)，并保證分布式數(shù)據(jù)記錄的最終一致性。
3. Seata in AT mode 的實現(xiàn)
第 2 章給出了實現(xiàn)實現(xiàn)分布式事務的集中常見的理論模型。本章給出業(yè)界開源分布式事務框架 Seata 的實現(xiàn)。
Seata 為用戶提供了 AT、TCC、SAGA 和 XA 事務模式。其中 AT 模式是 Seata 主推的事務模式，因此本章分析 Seata in AT mode 的實現(xiàn)。使用 AT 有一個前提，那就是微服務使用的數(shù)據(jù)庫必須是支持事務的關系型數(shù)據(jù)庫。
3.1. Seata in AT mode 工作流程概述
Seata 的 AT 模式建立在關系型數(shù)據(jù)庫的本地事務特性的基礎之上，通過數(shù)據(jù)源代理類攔截并解析數(shù)據(jù)庫執(zhí)行的 SQL，記錄自定義的回滾日志，如需回滾，則重放這些自定義的回滾日志即可。AT 模式雖然是根據(jù) XA 事務模型（2PC）演進而來的，但是 AT 打破了 XA 協(xié)議的阻塞性制約，在一致性和性能上取得了平衡。
AT 模式是基于 XA 事務模型演進而來的，它的整體機制也是一個改進版本的兩階段提交協(xié)議。AT 模式的兩個基本階段是：
1）第一階段：首先獲取本地鎖，執(zhí)行本地事務，業(yè)務數(shù)據(jù)操作和記錄回滾日志在同一個本地事務中提交，最后釋放本地鎖；
2）第二階段：如需全局提交，異步刪除回滾日志即可，這個過程很快就能完成。如需要回滾，則通過第一階段的回滾日志進行反向補償。
本章描述 Seata in AT mode 的工作原理使用的電商微服務模型如下圖所示：
在上圖中，協(xié)調(diào)者 shopping-service 先調(diào)用參與者 repo-service 扣減庫存，后調(diào)用參與者 order-service 生成訂單。這個業(yè)務流使用 Seata in XA mode 后的全局事務流程如下圖所示：
上圖描述的全局事務執(zhí)行流程為：
1）shopping-service 向 Seata 注冊全局事務，并產(chǎn)生一個全局事務標識 XID
2）將 repo-service.repo_db、order-service.order_db 的本地事務執(zhí)行到待提交階段，事務內(nèi)容包含對 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 匯報分支事務的提交狀態(tài)
6）Seata 匯總所有的 DB 的分支事務的提交狀態(tài)，決定全局事務是該提交還是回滾
7）Seata 通知 repo-service.repo_db、order-service.order_db 提交/回滾本地事務，若需要回滾，采取的是補償式方法
其中 1）2）3）4）5）屬于第一階段，6）7）屬于第二階段。
3.2. Seata in AT mode 工作流程詳述
在上面的電商業(yè)務場景中，購物服務調(diào)用庫存服務扣減庫存，調(diào)用訂單服務創(chuàng)建訂單，顯然這兩個調(diào)用過程要放在一個事務里面。即：
start global_trx
call 庫存服務的扣減庫存接口
call 訂單服務的創(chuàng)建訂單接口
commit global_trx
在庫存服務的數(shù)據(jù)庫中，存在如下的庫存表 t_repo：
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10001 | 20001 | xx 鍵盤 | 98 | 200.0 |
| 10002 | 20002 | yy 鼠標 | 199 | 100.0 |
在訂單服務的數(shù)據(jù)庫中，存在如下的訂單表 t_order：
| id | order_code | user_id | production_code | count | price |
|---|---|---|---|---|---|
| 30001 | 2020102500001 | 40001 | 20002 | 1 | 100.0 |
| 30002 | 2020102500001 | 40001 | 20001 | 2 | 400.0 |
現(xiàn)在，id 為 40002 的用戶要購買一只商品代碼為 20002 的鼠標，整個分布式事務的內(nèi)容為：
1）在庫存服務的庫存表中將記錄
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠標 | 199 | 100.0 |
修改為
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠標 | 198 | 100.0 |
2）在訂單服務的訂單表中添加一條記錄
| id | order_code | user_id | production_code | count | price |
|---|---|---|---|---|---|
| 30003 | 2020102500002 | 40002 | 20002 | 1 | 100.0 |
以上操作，在 AT 模式的第一階段的流程圖如下：
從 AT 模式第一階段的流程來看，分支的本地事務在第一階段提交完成之后，就會釋放掉本地事務鎖定的本地記錄。這是 AT 模式和 XA 最大的不同點，在 XA 事務的兩階段提交中，被鎖定的記錄直到第二階段結(jié)束才會被釋放。所以 AT 模式減少了鎖記錄的時間，從而提高了分布式事務的處理效率。AT 模式之所以能夠?qū)崿F(xiàn)第一階段完成就釋放被鎖定的記錄，是因為 Seata 在每個服務的數(shù)據(jù)庫中維護了一張 undo_log 表，其中記錄了對 t_order / t_repo 進行操作前后記錄的鏡像數(shù)據(jù)，即便第二階段發(fā)生異常，只需回放每個服務的 undo_log 中的相應記錄即可實現(xiàn)全局回滾。
undo_log 的表結(jié)構(gòu)：
| id | branch_id | xid | context | rollback_info | log_status | log_created | log_modified |
|---|---|---|---|---|---|---|---|
| …… | 分支事務 ID | 全局事務 ID | …… | 分支事務操作的記錄在事務前后的記錄鏡像，即 beforeImage 和 afterImage | …… | …… | …… |
第一階段結(jié)束之后，Seata 會接收到所有分支事務的提交狀態(tài)，然后決定是提交全局事務還是回滾全局事務。
1）若所有分支事務本地提交均成功，則 Seata 決定全局提交。Seata 將分支提交的消息發(fā)送給各個分支事務，各個分支事務收到分支提交消息后，會將消息放入一個緩沖隊列，然后直接向 Seata 返回提交成功。之后，每個本地事務會慢慢處理分支提交消息，處理的方式為：刪除相應分支事務的 undo_log 記錄。之所以只需刪除分支事務的 undo_log 記錄，而不需要再做其他提交操作，是因為提交操作已經(jīng)在第一階段完成了（這也是 AT 和 XA 不同的地方）。這個過程如下圖所示：
分支事務之所以能夠直接返回成功給 Seata，是因為真正關鍵的提交操作在第一階段已經(jīng)完成了，清除 undo_log 日志只是收尾工作，即便清除失敗了，也對整個分布式事務不產(chǎn)生實質(zhì)影響。
2）若任一分支事務本地提交失敗，則 Seata 決定全局回滾，將分支事務回滾消息發(fā)送給各個分支事務，由于在第一階段各個服務的數(shù)據(jù)庫上記錄了 undo_log 記錄，分支事務回滾操作只需根據(jù) undo_log 記錄進行補償即可。全局事務的回滾流程如下圖所示：
這里對圖中的 2、3 步做進一步的說明：
1）由于上文給出了 undo_log 的表結(jié)構(gòu)，所以可以通過 xid 和 branch_id 來找到當前分支事務的所有 undo_log 記錄；
2）拿到當前分支事務的 undo_log 記錄之后，首先要做數(shù)據(jù)校驗，如果 afterImage 中的記錄與當前的表記錄不一致，說明從第一階段完成到此刻期間，有別的事務修改了這些記錄，這會導致分支事務無法回滾，向 Seata 反饋回滾失敗；如果 afterImage 中的記錄與當前的表記錄一致，說明從第一階段完成到此刻期間，沒有別的事務修改這些記錄，分支事務可回滾，進而根據(jù) beforeImage 和 afterImage 計算出補償 SQL，執(zhí)行補償 SQL 進行回滾，然后刪除相應 undo_log，向 Seata 反饋回滾成功。
事務具有 ACID 特性，全局事務解決方案也在盡量實現(xiàn)這四個特性。以上關于 Seata in AT mode 的描述很顯然體現(xiàn)出了 AT 的原子性、一致性和持久性。下面著重描述一下 AT 如何保證多個全局事務的隔離性的。
在 AT 中，當多個全局事務操作同一張表時，通過全局鎖來保證事務的隔離性。下面描述一下全局鎖在讀隔離和寫隔離兩個場景中的作用原理：
1）寫隔離（若有全局事務在改/寫/刪記錄，另一個全局事務對同一記錄進行的改/寫/刪要被隔離起來，即寫寫互斥）：寫隔離是為了在多個全局事務對同一張表的同一個字段進行更新操作時，避免一個全局事務在沒有被提交成功之前所涉及的數(shù)據(jù)被其他全局事務修改。寫隔離的基本原理是：在第一階段本地事務（開啟本地事務的時候，本地事務會對涉及到的記錄加本地鎖）提交之前，確保拿到全局鎖。如果拿不到全局鎖，就不能提交本地事務，并且不斷嘗試獲取全局鎖，直至超出重試次數(shù)，放棄獲取全局鎖，回滾本地事務，釋放本地事務對記錄加的本地鎖。
假設有兩個全局事務 gtrx_1 和 gtrx_2 在并發(fā)操作庫存服務，意圖扣減如下記錄的庫存數(shù)量：
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠標 | 198 | 100.0 |
AT 實現(xiàn)寫隔離過程的時序圖如下：
圖中，1、2、3、4 屬于第一階段，5 屬于第二階段。
在上圖中 gtrx_1 和 gtrx_2 均成功提交，如果 gtrx_1 在第二階段執(zhí)行回滾操作，那么 gtrx_1 需要重新發(fā)起本地事務獲取本地鎖，然后根據(jù) undo_log 對這個 id=10002 的記錄進行補償式回滾。此時 gtrx_2 仍在等待全局鎖，且持有這個 id=10002 的記錄的本地鎖，因此 gtrx_1 會回滾失敗（gtrx_1 回滾需要同時持有全局鎖和對 id=10002 的記錄加的本地鎖），回滾失敗的 gtrx_1 會一直重試回滾。直到旁邊的 gtrx_2 獲取全局鎖的嘗試次數(shù)超過閾值，gtrx_2 會放棄獲取全局鎖，發(fā)起本地回滾，本地回滾結(jié)束后，自然會釋放掉對這個 id=10002 的記錄加的本地鎖。此時，gtrx_1 終于可以成功對這個 id=10002 的記錄加上了本地鎖，同時拿到了本地鎖和全局鎖的 gtrx_1 就可以成功回滾了。整個過程，全局鎖始終在 gtrx_1 手中，并不會發(fā)生臟寫的問題。整個過程的流程圖如下所示：
2）讀隔離（若有全局事務在改/寫/刪記錄，另一個全局事務對同一記錄的讀取要被隔離起來，即讀寫互斥）：在數(shù)據(jù)庫本地事務的隔離級別為讀已提交、可重復讀、串行化時（讀未提交不起什么隔離作用，一般不使用），Seata AT 全局事務模型產(chǎn)生的隔離級別是讀未提交，也就是說一個全局事務會看到另一個全局事務未全局提交的數(shù)據(jù)，產(chǎn)生臟讀，從前文的第一階段和第二階段的流程圖中也可以看出這一點。這在最終一致性的分布式事務模型中是可以接受的。
如果要求 AT 模型一定要實現(xiàn)讀已提交的事務隔離級別，可以利用 Seata 的 SelectForUpdateExecutor 執(zhí)行器對 SELECT FOR UPDATE 語句進行代理。SELECT FOR UPDATE 語句在執(zhí)行時會申請全局鎖，如果全局鎖已經(jīng)被其他全局事務占有，則回滾 SELECT FOR UPDATE 語句的執(zhí)行，釋放本地鎖，并且重試 SELECT FOR UPDATE 語句。在這個過程中，查詢請求會被阻塞，直到拿到全局鎖（也就是要讀取的記錄被其他全局事務提交），讀到已被全局事務提交的數(shù)據(jù)才返回。這個過程如下圖所示：
4. 結(jié)束語
XA 協(xié)議是 X/Open 提出的分布式事務處理標準。文中提到的 2PC、3PC、TCC、本地事務表、Seata in AT mode，無論哪一種，本質(zhì)都是事務協(xié)調(diào)者協(xié)調(diào)各個事務參與者的本地事務的進度，使使所有本地事務共同提交或回滾，最終達成一種全局的 ACID 特性。在協(xié)調(diào)的過程中，協(xié)調(diào)者需要收集各個本地事務的當前狀態(tài)，并根據(jù)這些狀態(tài)發(fā)出下一階段的操作指令。這個思想就是 XA 協(xié)議的要義，我們可以說這些事務模型遵守或大致遵守了 XA 協(xié)議。
基于消息中間件的最終一致性事務方案是互聯(lián)網(wǎng)公司在高并發(fā)場景中探索出的一種創(chuàng)新型應用模式，利用 MQ 實現(xiàn)微服務之間的異步調(diào)用、解耦合和流量削峰，保證分布式數(shù)據(jù)記錄的最終一致性。它顯然不遵守 XA 協(xié)議。
對于某項技術，可能存在業(yè)界標準或協(xié)議，但實踐者針對具體應用場景的需求或者出于簡便的考慮，給出與標準不完全相符的實現(xiàn)，甚至完全不相符的實現(xiàn)，這在工程領域是一種常見的現(xiàn)象。TCC 方案如此、基于消息中間件的最終一致性事務方案如此、Seata in AT mode 模式也如此。而新的標準往往就在這些創(chuàng)新中產(chǎn)生。
。
。
。
。
你難道真的沒有發(fā)現(xiàn) 2.6 節(jié)（基于消息中間件的最終一致性事務方案）給出的正確方案中存在的業(yè)務漏洞嗎？請各位重新看下這張圖，仔細品一品兩個微服務的調(diào)用方向，把你的想法留在評論區(qū)吧 :-)
還不過癮？試試它們