分布式事務，咱們前邊也聊過很多次了，網上其實也有不少文章在介紹分布式事務，不過里邊都會涉及到不少專業名詞，看的大家云里霧里，所以還是有一些小伙伴在微信上問我。

那么今天，我就再來一篇文章，和大家捋一捋這個話題。以下的內容主要圍繞阿里的 seata 來和大家解釋。

1. 什么是反向補償

首先，來和大家解釋一個名詞，大家在看分布式事務相關資料的時候，經常會看到一個名詞：反向補償。啥是反向補償呢?

我舉一個例子：假設我們現在有三個微服務分別是 A、B、C，現在在 A 服務中分別調用 B 和 C 服務，為了確保 B 和 C 同時成功或者同時失敗，我們需要使用到分布式事務。但是按照我們之前對本地事務的理解，B 和 C 中的本地事務，當 B 服務中的事務執行完畢并且提交之后，現在 C 服務中的事務出現異常需要回滾了，但是，B 已經提交了還怎么回滾呀?

此時我們所說的回滾其實并不是傳統意義上的，通過 MySQL redo log 日志來回滾的那種，而是通過一條更新 SQL，再把 B 服務中已經更改過的數據復原。

這就是我們所說的反向補償!

2. 基本概念梳理

Seata 中有三個核心概念：

• TC (Transaction Coordinator) - 事務協調者：維護全局和分支事務的狀態，驅動全局事務提交或回滾。
• TM (Transaction Manager) - 事務管理器：定義全局事務的范圍，開始全局事務、提交或回滾全局事務。
• RM ( Resource Manager ) - 資源管理器：管理分支事務處理的資源( Resource )，與 TC 交談以注冊分支事務和報告分支事務的狀態，并驅動分支事務提交或回滾。
  

其中，TC 為單獨部署的 Server 服務端，TM 和 RM 為嵌入到應用中的 Client 客戶端。我們來看如下一張圖片：

這張圖基本上把這個三個概念解釋清楚了。

其實不看這張圖，我們大概也能猜到分布式事務的實現原理：首先得有一個全局的事務協調者(TC)，各個本地事務(RM)在開始執行的時候，或者在執行的過程中，及時將自己的狀態報告給全局事務協調者，這個全局事務協調者知道每一個分支事務目前的執行狀態，當他(TC)發現所有的本地事務都執行成功的時候，就通知大家一起提交;當他發現在本次事務中，有人執行失敗的時候，就通知大家一起回滾(當然這個回滾不一定是真的回滾，而是反向補償)。那么一個事務什么時候開始什么時候結束呢?也就是事務的邊界在哪里?seata 中的分布式事務都是通過 @GlobalTransactional 注解來實現的，換句話說，這個注解該加在哪里?添加該注解的地方其實就是事務管理器 TM 了。

經過上面的介紹，小伙伴們應該明白了，其實用 Seata 實現分布式事務沒有想象的那么難，原理還是非常 Easy 的。

Seata 中涉及到四種不同的模式，接下來介紹的四種不同模式，其實都是在說當有一個本地事務失敗的時候，該如何回滾?這就是我們后面要說的四種不同的分布式事務模式了。

3. 什么是兩階段提交

先來看下面一張圖：

這張圖里涉及到三個概念：

• AP：這個不用多說，AP 就是應用程序本身。
• RM：RM 是資源管理器，也就是事務的參與者，大部分情況下就是指數據庫，一個分布式事務往往涉及到多個 RM。
• TM：TM 就是事務管理器，創建分布式事務并協調分布式事務中的各個子事務的執行和狀態，子事務就是指在 RM 上執行的具體操作。

那么什么是兩階段(Two-Phase Commit, 簡稱 2PC)提交?

兩階段提交說白了道理很簡單，松哥舉個簡單例子來和大家說明兩階段提交：

比如下面一張圖：

我們在 Business 中分別調用 Storage 與 Order、Account，這三個中的操作要同時成功或者同時失敗，但是由于這三個分處于不同服務，因此我們只能先讓這三個服務中的操作各自執行，三個服務中的事務各自執行就是兩階段中的第一階段。

第一階段執行完畢后，先不要急著提交，因為三個服務中有的可能執行失敗了，此時需要三個服務各自把自己一階段的執行結果報告給一個事務協調者，事務協調者收到消息后，如果三個服務的一階段都執行成功了，此時就通知三個事務分別提交，如果三個服務中有服務執行失敗了，此時就通知三個事務分別回滾。

這就是所謂的兩階段提交。

總結一下：兩階段提交中，事務分為參與者(例如上圖的各個具體服務)與協調者，參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是要提交操作還是中止操作，這里的參與者可以理解為 RM，協調者可以理解為 TM。

不過 Seata 中的各個分布式事務模式，基本都是在二階段提交的基礎上演化出來的，因此并不完全一樣，這點需要小伙伴們注意。

4. AT 模式

AT 模式是一種全自動的事務回滾模式。

整體上來說，AT 模式是兩階段提交協議的演變：

• 一階段：業務數據和回滾日志記錄在同一個本地事務中提交，釋放本地鎖和連接資源。
• 二階段則分兩種情況：2.1 提交異步化，非常快速地完成。2.2 回滾通過一階段的回滾日志進行反向補償。

大致上的邏輯就是上面這樣，我們通過一個具體的案例來看看 AT 模式是如何工作的：

假設有一個業務表 product，如下：

現在我們想做如下一個更新操作：

update product set name = 'GTS' where name = 'TXC';

步驟如下：

一階段：

• 解析 SQL：得到 SQL 的類型(UPDATE)，表(product)，條件(where name = 'TXC')等相關的信息。
• 查詢前鏡像：根據解析得到的條件信息，生成查詢語句，定位數據(查找到更新之前的數據)。
• 執行上面的更新 SQL。
• 查詢后鏡像：根據前鏡像的結果，通過主鍵定位數據。
• 插入回滾日志：把前后鏡像數據以及業務 SQL 相關的信息組成一條回滾日志記錄，插入到 UNDO_LOG 表中。
• 提交前，向 TC 注冊分支：申請 product 表中，主鍵值等于 1 的記錄的 全局鎖。
• 本地事務提交：業務數據的更新和前面步驟中生成的 UNDO LOG 一并提交。
• 將本地事務提交的結果上報給 TC。

二階段：

二階段分兩種情況，提交或者回滾。

先來看回滾步驟：

• 首先收到 TC 的分支回滾請求，開啟一個本地事務，執行如下操作。
• 通過 XID 和 Branch ID 查找到相應的 UNDO LOG 記錄(這條記錄中保存了數據修改前后對應的鏡像)。
• 數據校驗：拿 UNDO LOG 中的后鏡像與當前數據進行比較，如果有不同，說明數據被當前全局事務之外的動作做了修改。這種情況，需要根據配置策略來做處理。
  
• 根據 UNDO LOG 中的前鏡像和業務 SQL 的相關信息生成并執行回滾的語句：update product set name = 'TXC' where id = 1;
  
• 提交本地事務。并把本地事務的執行結果(即分支事務回滾的結果)上報給 TC。

再來看提交步驟：

• 收到 TC 的分支提交請求，把請求放入一個異步任務的隊列中，馬上返回提交成功的結果給 TC。
• 異步任務階段的分支提交請求將異步和批量地刪除相應 UNDO LOG 記錄。

大致上就是這樣一個步驟，思路還是比較清晰的，就是當你要更新一條記錄的時候，系統將這條記錄更新之前和更新之后的內容生成一段 JSON 并存入 undo log 表中，將來要回滾的話，就根據 undo log 中的記錄去更新數據(反向補償)，將來要是不回滾的話，就刪除 undo log 中的記錄。

在整個過程中，開發者只需要額外創建一張 undo log 表就行了，然后給需要處理全局事務的地方加上 @GlobalTransactional 注解就行了。

其他的提交呀回滾呀都是全自動的，比較省事。所以如果你項目中選擇了用 seata 來處理分布式事務，那么用 AT 模式的概率還是相當高的。

5. TCC 模式

TCC(Try-Confirm-Cancel) 模式就帶一點手動的感覺了，它也是兩階段，但是和 AT 又不太一樣，我們來看下流程。

官網上有一張 TCC 的流程圖，我們來看下：

可以看到，TCC 也是分為兩階段：

• 第一階段是 prepare，在這個階段主要是做資源的檢測和預留工作，例如銀行轉賬，這個階段就先去檢查下用戶的錢夠不夠，不夠就直接拋異常，夠就先給凍結上。
• 第二階段是 commit 或 rollback，這個主要是等各個分支事務的一階段都執行完畢，都執行完畢后各自將自己的情況報告給 TC，TC 一統計，發現各個分支事務都沒有異常，那么就通知大家一起提交;如果 TC 發現有分支事務發生異常了，那么就通知大家回滾。
  

那么小伙伴可能也發現了，上面這個流程中，一共涉及到了三個方法，prepare、commit 以及
rollback，這三個方法都完全是用戶自定義的方法，都是需要我們自己來實現的，所以我一開始就說 TCC 是一種手動的模式。

和 AT 相比，大家發現 TCC 這種模式其實是不依賴于底層數據庫的事務支持的，也就是說，哪怕你底層數據庫不支持事務也沒關系，反正 prepare、commit 以及 rollback 三個方法都是開發者自己寫的，我們自己將這三個方法對應的流程捋順就行了。

6. XA 模式

如果小伙伴們懂得 MySQL 數據庫的 XA 事務，那么一下子就懂得 seata 中的 XA 模式是咋回事了。

XA 規范是 X/Open 組織定義的分布式事務處理(DTP，Distributed Transaction Processing)標準。

XA 規范描述了全局的事務管理器與局部的資源管理器之間的接口。XA規范的目的是允許的多個資源(如數據庫，應用服務器，消息隊列等)在同一事務中訪問，這樣可以使 ACID 屬性跨越應用程序而保持有效。

XA 規范使用兩階段提交來保證所有資源同時提交或回滾任何特定的事務。

XA 規范在上世紀 90 年代初就被提出。目前，幾乎所有主流的數據庫都對 XA 規范提供了支持。

XA 事務的基礎是兩階段提交協議。需要有一個事務協調者來保證所有的事務參與者都完成了準備工作(第一階段)。如果協調者收到所有參與者都準備好的消息，就會通知所有的事務都可以提交了(第二階段)。MySQL 在這個 XA 事務中扮演的是參與者的角色，而不是協調者(事務管理器)。

MySQL 的 XA 事務分為內部 XA 和外部 XA。外部 XA 可以參與到外部的分布式事務中，需要應用層介入作為協調者;內部 XA 事務用于同一實例下跨多引擎事務，由 Binlog 作為協調者，比如在一個存儲引擎提交時，需要將提交信息寫入二進制日志，這就是一個分布式內部 XA
事務，只不過二進制日志的參與者是 MySQL 本身。MySQL 在 XA 事務中扮演的是一個參與者的角色，而不是協調者。

換言之，MySQL 天然的就可以通過 XA 規范來實現分布式事務，只不過需要借助一些外部應用的支持。我們來看下 Seata 中的 XA 模式使用流程。

先來看一張來自官方的圖片：

可以看到，這也是一個兩階段提交：

• 一階段：業務 SQL 操作放在 XA 分支中進行，XA 分支完成后，執行 XA prepare，由 RM 對 XA 協議的支持來保證持久化(即之后任何意外都不會造成無法回滾的情況)。
• 二階段分兩種情況：提交或者回滾：

分支提交：執行 XA 分支的 commit

分支回滾：執行 XA 分支的 rollback

和前面兩種模式的區別在于，XA 模式中的回滾，是正兒八經的回滾，是我們傳統意義上所理解的回滾，而不是一種反向補償。

7. Saga 模式

’最后再來看看 saga 模式，這種模式應用很少，大家作為了解即可。

saga 模式是 seata 提供的長事務解決方案，然而長事務是我們在開發中應該避免的，因為效率低并且容易造成死鎖。

這個 saga 模式就有點像流程引擎，開發者先自己畫一個流程引擎，把整個事務中涉及到的方法都囊括進來，每一個方法返回什么的時候就是正常的，返回什么就是異常的，正常的就繼續往下走，異常的就執行另一套流程，也就是我們需要提前準備好兩套方法，第一套是各種正常情況的執行流程，第二套則是發生異常之后的執行流程，類似下面這樣：

綠色的都是正常的流程，紅色的則是發生異常后回滾的流程。回滾中也是一種反向補償。

8. 小結

好啦，分布式事務 4 種模式就和大家說清楚啦～后面有空整幾個案例一起實踐下!