Java?SpringBoot分布式事務(wù)問題如何解決

這篇文章主要介紹“Java SpringBoot分布式事務(wù)問題如何解決”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Java SpringBoot分布式事務(wù)問題如何解決”文章能幫助大家解決問題。

1. 什么是反向補(bǔ)償

首先，來和大家解釋一個(gè)名詞，大家在看分布式事務(wù)相關(guān)資料的時(shí)候，經(jīng)常會(huì)看到一個(gè)名詞：反向補(bǔ)償。啥是反向補(bǔ)償呢？

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

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

這就是我們所說的反向補(bǔ)償！

2. 基本概念梳理

Seata 中有三個(gè)核心概念：

• TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者：維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局事務(wù)提交或回滾。

• TM (Transaction Manager) - 事務(wù)管理器：定義全局事務(wù)的范圍，開始全局事務(wù)、提交或回滾全局事務(wù)。

• RM ( Resource Manager ) - 資源管理器：管理分支事務(wù)處理的資源( Resource )，與 TC 交談以注冊(cè)分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)提交或回滾。

其中，TC 為單獨(dú)部署的 Server 服務(wù)端，TM 和 RM 為嵌入到應(yīng)用中的 Client 客戶端。

我們來看如下一張圖片：

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

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

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

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

3. 什么是兩階段提交

先來看下面一張圖：

這張圖里涉及到三個(gè)概念：

• AP：這個(gè)不用多說，AP 就是應(yīng)用程序本身。

• RM：RM 是資源管理器，也就是事務(wù)的參與者，大部分情況下就是指數(shù)據(jù)庫(kù)，一個(gè)分布式事務(wù)往往涉及到多個(gè) RM。

• TM：TM 就是事務(wù)管理器，創(chuàng)建分布式事務(wù)并協(xié)調(diào)分布式事務(wù)中的各個(gè)子事務(wù)的執(zhí)行和狀態(tài)，子事務(wù)就是指在 RM 上執(zhí)行的具體操作。

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

兩階段提交說白了道理很簡(jiǎn)單，松哥舉個(gè)簡(jiǎn)單例子來和大家說明兩階段提交：

比如下面一張圖：

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

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

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

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

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

4. AT 模式

AT 模式是一種全自動(dòng)的事務(wù)回滾模式。

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

• 一階段：業(yè)務(wù)數(shù)據(jù)和回滾日志記錄在同一個(gè)本地事務(wù)中提交，釋放本地鎖和連接資源。

• 二階段則分兩種情況：2.1 提交異步化，非?？焖俚赝瓿伞?.2 回滾通過一階段的回滾日志進(jìn)行反向補(bǔ)償。

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

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

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

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

步驟如下：

一階段：

• 解析 SQL：得到 SQL 的類型（UPDATE），表（product），條件（where name = 'TXC'）等相關(guān)的信息。

• 查詢前鏡像：根據(jù)解析得到的條件信息，生成查詢語句，定位數(shù)據(jù)（查找到更新之前的數(shù)據(jù)）。

• 執(zhí)行上面的更新 SQL。

• 查詢后鏡像：根據(jù)前鏡像的結(jié)果，通過主鍵定位數(shù)據(jù)。

• 插入回滾日志：把前后鏡像數(shù)據(jù)以及業(yè)務(wù) SQL 相關(guān)的信息組成一條回滾日志記錄，插入到 UNDO_LOG 表中。

• 提交前，向 TC 注冊(cè)分支：申請(qǐng) product 表中，主鍵值等于 1 的記錄的 全局鎖。

• 本地事務(wù)提交：業(yè)務(wù)數(shù)據(jù)的更新和前面步驟中生成的 UNDO LOG 一并提交。

• 將本地事務(wù)提交的結(jié)果上報(bào)給 TC。

二階段：

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

先來看回滾步驟：

• 首先收到 TC 的分支回滾請(qǐng)求，開啟一個(gè)本地事務(wù)，執(zhí)行如下操作。

• 通過 XID 和 Branch ID 查找到相應(yīng)的 UNDO LOG 記錄（這條記錄中保存了數(shù)據(jù)修改前后對(duì)應(yīng)的鏡像）。

• 數(shù)據(jù)校驗(yàn)：拿 UNDO LOG 中的后鏡像與當(dāng)前數(shù)據(jù)進(jìn)行比較，如果有不同，說明數(shù)據(jù)被當(dāng)前全局事務(wù)之外的動(dòng)作做了修改。這種情況，需要根據(jù)配置策略來做處理。

• 根據(jù) UNDO LOG 中的前鏡像和業(yè)務(wù) SQL 的相關(guān)信息生成并執(zhí)行回滾的語句：update product set name = 'TXC' where id = 1;

• 提交本地事務(wù)。并把本地事務(wù)的執(zhí)行結(jié)果（即分支事務(wù)回滾的結(jié)果）上報(bào)給 TC。

再來看提交步驟：

• 收到 TC 的分支提交請(qǐng)求，把請(qǐng)求放入一個(gè)異步任務(wù)的隊(duì)列中，馬上返回提交成功的結(jié)果給 TC。

• 異步任務(wù)階段的分支提交請(qǐng)求將異步和批量地刪除相應(yīng) UNDO LOG 記錄。

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

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

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

5. TCC 模式

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

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

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

• 第一階段是 prepare，在這個(gè)階段主要是做資源的檢測(cè)和預(yù)留工作，例如銀行轉(zhuǎn)賬，這個(gè)階段就先去檢查下用戶的錢夠不夠，不夠就直接拋異常，夠就先給凍結(jié)上。

• 第二階段是 commit 或 rollback，這個(gè)主要是等各個(gè)分支事務(wù)的一階段都執(zhí)行完畢，都執(zhí)行完畢后各自將自己的情況報(bào)告給 TC，TC 一統(tǒng)計(jì)，發(fā)現(xiàn)各個(gè)分支事務(wù)都沒有異常，那么就通知大家一起提交；如果 TC 發(fā)現(xiàn)有分支事務(wù)發(fā)生異常了，那么就通知大家回滾。

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

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

6. XA 模式

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

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

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

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

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

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

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

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

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

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

• 一階段：業(yè)務(wù) SQL 操作放在 XA 分支中進(jìn)行，XA 分支完成后，執(zhí)行 XA prepare，由 RM 對(duì) XA 協(xié)議的支持來保證持久化（即之后任何意外都不會(huì)造成無法回滾的情況）。

• 二階段分兩種情況：提交或者回滾：

• 分支提交：執(zhí)行 XA 分支的 commit

• 分支回滾：執(zhí)行 XA 分支的 rollback

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

7. Saga 模式

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

saga 模式是 seata 提供的長(zhǎng)事務(wù)解決方案，然而長(zhǎng)事務(wù)是我們?cè)陂_發(fā)中應(yīng)該避免的，因?yàn)樾实筒⑶胰菀自斐伤梨i。

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

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

關(guān)于“Java SpringBoot分布式事務(wù)問題如何解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。