腳本之家服務器常用軟件

快捷導航

一文搞明白Java?Spring?Boot分布式事務解決方案

更新時間：2022年07月11日 10:17:39 作者：?江南一點雨?

這篇文章主要介紹了一文搞明白Java?Spring?Boot分布式事務解決方案，文章圍繞主題展開詳細的內容介紹，具有一定的參考價值，需要的小伙伴可以參考一下

前言

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

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

1. 什么是反向補償

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

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

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

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

2. 基本概念梳理

Seata 中有三個核心概念：

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

其中，TC 為單獨部署的 Server 服務端，TM 和 RM 為嵌入到應用中的 Client 客戶端。

我們來看如下一張圖片：

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

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

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

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

3. 什么是兩階段提交

先來看下面一張圖：

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

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

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

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

比如下面一張圖：

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

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

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

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

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

4. AT 模式

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

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

一階段：業(yè)務數(shù)據(jù)和回滾日志記錄在同一個本地事務中提交，釋放本地鎖和連接資源。
二階段則分兩種情況：2.1 提交異步化，非?？焖俚赝瓿伞?.2 回滾通過一階段的回滾日志進行反向補償。

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

假設有一個業(yè)務表 product，如下：

現(xiàn)在我們想做如下一個更新操作：

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

步驟如下：

一階段：

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

二階段：

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

先來看回滾步驟：

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

再來看提交步驟：

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

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

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

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

5. TCC 模式

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

官網(wǎng)上有一張 TCC 的流程圖，我們來看下：

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

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

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

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

6. XA 模式

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

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

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

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

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

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

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

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

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

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

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

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

7. Saga 模式

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

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

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