一文搞明白分布式事務(wù)解決方案！真的 So Easy！

作者：江南一點(diǎn)雨 2022-05-30 10:37:35

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

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

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

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

首先，來(lái)和大家解釋一個(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í)我們所說(shuō)的回滾其實(shí)并不是傳統(tǒng)意義上的，通過(guò) MySQL redo log 日志來(lái)回滾的那種，而是通過(guò)一條更新 SQL，再把 B 服務(wù)中已經(jīng)更改過(guò)的數(shù)據(jù)復(fù)原。

這就是我們所說(shuō)的反向補(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 客戶端。我們來(lái)看如下一張圖片：

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

其實(shí)不看這張圖，我們大概也能猜到分布式事務(wù)的實(shí)現(xiàn)原理：首先得有一個(gè)全局的事務(wù)協(xié)調(diào)者(TC)，各個(gè)本地事務(wù)(RM)在開始執(zhí)行的時(shí)候，或者在執(zhí)行的過(guò)程中，及時(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ù)都是通過(guò) @GlobalTransactional 注解來(lái)實(shí)現(xiàn)的，換句話說(shuō)，這個(gè)注解該加在哪里?添加該注解的地方其實(shí)就是事務(wù)管理器 TM 了。

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

3. 什么是兩階段提交

先來(lái)看下面一張圖：

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

AP：這個(gè)不用多說(shuō)，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)提交?

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

比如下面一張圖：

我們?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。

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

4. AT 模式

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

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

一階段：業(yè)務(wù)數(shù)據(jù)和回滾日志記錄在同一個(gè)本地事務(wù)中提交，釋放本地鎖和連接資源。
二階段則分兩種情況：2.1 提交異步化，非常快速地完成。2.2 回滾通過(guò)一階段的回滾日志進(jìn)行反向補(bǔ)償。

大致上的邏輯就是上面這樣，我們通過(guò)一個(gè)具體的案例來(lái)看看 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ù)解析得到的條件信息，生成查詢語(yǔ)句，定位數(shù)據(jù)(查找到更新之前的數(shù)據(jù))。
執(zhí)行上面的更新 SQL。
查詢后鏡像：根據(jù)前鏡像的結(jié)果，通過(guò)主鍵定位數(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。

二階段：

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

先來(lái)看回滾步驟：

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

再來(lái)看提交步驟：

收到 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 表中，將來(lái)要回滾的話，就根據(jù) undo log 中的記錄去更新數(shù)據(jù)(反向補(bǔ)償)，將來(lái)要是不回滾的話，就刪除 undo log 中的記錄。

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

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

5. TCC 模式

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

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

可以看到，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è)方法都完全是用戶自定義的方法，都是需要我們自己來(lái)實(shí)現(xiàn)的，所以我一開始就說(shuō) TCC 是一種手動(dòng)的模式。

和 AT 相比，大家發(fā)現(xiàn) TCC 這種模式其實(shí)是不依賴于底層數(shù)據(jù)庫(kù)的事務(wù)支持的，也就是說(shuō)，哪怕你底層數(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ù)中訪問(wèn)，這樣可以使 ACID 屬性跨越應(yīng)用程序而保持有效。

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

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

XA 事務(wù)的基礎(chǔ)是兩階段提交協(xié)議。需要有一個(gè)事務(wù)協(xié)調(diào)者來(lái)保證所有的事務(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ù)，只不過(guò)二進(jìn)制日志的參與者是 MySQL 本身。MySQL 在 XA 事務(wù)中扮演的是一個(gè)參與者的角色，而不是協(xié)調(diào)者。

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

先來(lái)看一張來(lái)自官方的圖片：

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

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

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

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

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

7. Saga 模式

’最后再來(lái)看看 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)來(lái)，每一個(gè)方法返回什么的時(shí)候就是正常的，返回什么就是異常的，正常的就繼續(xù)往下走，異常的就執(zhí)行另一套流程，也就是我們需要提前準(zhǔn)備好兩套方法，第一套是各種正常情況的執(zhí)行流程，第二套則是發(fā)生異常之后的執(zhí)行流程，類似下面這樣：