一、Seata 概述

Seata是Simple Extensible Autonomous Transaction Architecture的簡寫，由feascar改名而來。

Seata 是阿里開源的分布式事務框架，屬于二階段提交模式。

目前github上已經(jīng)有12267顆星了，也很活躍，最新的提交時間很多都是幾天前。

首先我們回顧一下在單體應用中，例如一個業(yè)務調(diào)用了3個模塊，他們都使用同一個數(shù)據(jù)源，是靠本地事務來保證事務一致性。

但在微服務架構(gòu)中，這3個模塊會變?yōu)?個獨立的微服務，各自有自己的數(shù)據(jù)源，調(diào)用邏輯就變?yōu)椋?/p>

Seata 如何處理呢？

Business 是業(yè)務入口，在程序中會通過注解來說明他是一個全局事務，這時他的角色為 TM（事務管理者）。

Business 會請求 TC（事務協(xié)調(diào)器，一個獨立運行的服務），說明自己要開啟一個全局事務，TC 會生成一個全局事務ID（XID），并返回給 Business。

Business 得到 XID 后，開始調(diào)用微服務，例如調(diào)用 Storage。

（和上面的圖一樣，方便查看，防止?jié)L到到這兒時已經(jīng)看不到上面的圖片了）

Storage 會收到 XID，知道自己的事務屬于這個全局事務。Storage 執(zhí)行自己的業(yè)務邏輯，操作本地數(shù)據(jù)庫。

Storage 會把自己的事務注冊到 TC，作為這個 XID 下面的一個分支事務，并且把自己的事務執(zhí)行結(jié)果也告訴 TC。

此時 Storage 的角色是 RM（資源管理者），資源是指本地數(shù)據(jù)庫。

Order、Account 的執(zhí)行邏輯與 Storage 一致。

在各個微服務都執(zhí)行完成后，TC 可以知道 XID 下各個分支事務的執(zhí)行結(jié)果，TM（Business） 也就知道了。

Business 如果發(fā)現(xiàn)各個微服務的本地事務都執(zhí)行成功了，就請求 TC 對這個 XID 提交，否則回滾。

TC 收到請求后，向 XID 下的所有分支事務發(fā)起相應請求。

各個微服務收到 TC 的請求后，執(zhí)行相應指令，并把執(zhí)行結(jié)果上報 TC。

重要機制

（1）全局事務的回滾是如何實現(xiàn)的呢？

Seata 有一個重要的機制：回滾日志。

每個分支事務對應的數(shù)據(jù)庫中都需要有一個回滾日志表 UNDO_LOG，在真正修改數(shù)據(jù)庫記錄之前，都會先記錄修改前的記錄值，以便之后回滾。

在收到回滾請求后，就會根據(jù)UNDO_LOG生成回滾操作的 SQL 語句來執(zhí)行。

如果收到的是提交請求，就把UNDO_LOG中的相應記錄刪除掉。

（2）RM 是怎么自動和 TC 交互的？

是通過監(jiān)控攔截JDBC實現(xiàn)的，例如監(jiān)控到開啟本地事務了，就會自動向 TC 注冊、生成回滾日志、向 TC 匯報執(zhí)行結(jié)果。

（3）二階段回滾失敗怎么辦？

例如 TC 命令各個 RM 回滾的時候，有一個微服務掛掉了，那么所有正常的微服務也都不會執(zhí)行回滾，當這個微服務重新正常運行后，TC 會重新執(zhí)行全局回滾。

1.3 核心組件

回顧一下其中的核心組件：

事務協(xié)調(diào)器 TC

維護全局和分支事務的狀態(tài)，指示全局提交或者回滾。

事務管理者 TM

開啟、提交或者回滾一個全局事務。

資源管理者 RM

管理執(zhí)行分支事務的那些資源，向TC注冊分支事務、上報分支事務狀態(tài)、控制分支事務的提交或者回滾。

1.4 具體工作過程

再從宏觀上梳理一下 Seata 的工作過程：

TM 請求 TC，開始一個新的全局事務，TC 會為這個全局事務生成一個 XID。
XID 通過微服務的調(diào)用鏈傳遞到其他微服務。
RM 把本地事務作為這個XID的分支事務注冊到TC。
TM 請求 TC 對這個 XID 進行提交或回滾。
TC 指揮這個 XID 下面的所有分支事務進行提交、回滾。

二、Seata 詳細工作流程示例

下面我們通過一個分支事務的執(zhí)行過程來了解 Seata 的工作流程。

例如有一個業(yè)務表product(id,name)，分支事務的業(yè)務邏輯：

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

2.1 一階段

（1）解析 SQL

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

（2）查詢前鏡像

根據(jù)解析得到的條件信息，生成查詢語句，定位數(shù)據(jù)。

select id, name from product where name = 'TXC';

得到前鏡像：

id	name
1	TXC

（3）執(zhí)行業(yè)務 SQL

執(zhí)行自己的業(yè)務邏輯：

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

把name改為了GTS。

（4）查詢后鏡像

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

select id, name from product where id = 1;

得到后鏡像：

id	name
1	GTS

（5）插入回滾日志

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

（6）提交前，向 TC 注冊分支：申請product表中，主鍵值等于 1 的記錄的 全局鎖 。

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

（8）將本地事務提交的結(jié)果上報給 TC。

2.2 二階段 - 回滾

（1）收到 TC 的分支回滾請求，開啟一個本地事務，執(zhí)行如下操作。

（2）通過 XID 和 Branch ID 查找到相應的 UNDO LOG 記錄。

（3）數(shù)據(jù)校驗

拿 UNDO LOG 中的后鏡與當前數(shù)據(jù)進行比較，根據(jù)校驗結(jié)果決定是否做回滾。

（4）根據(jù) UNDO LOG 中的前鏡像和業(yè)務 SQL 的相關(guān)信息生成并執(zhí)行回滾的語句：

update product set name = 'TXC' where id = 1;

（5）提交本地事務

并把本地事務的執(zhí)行結(jié)果（即分支事務回滾的結(jié)果）上報給 TC。

二階段 - 提交

（1）收到 TC 的分支提交請求，把請求放入一個異步任務的隊列中，馬上返回提交成功的結(jié)果給 TC。

（2）異步任務階段的分支提交請求，將異步和批量地刪除相應 UNDO LOG 記錄。

三、小結(jié)

上面介紹的是 Seata 的AT 模式，就是自動化事務，使用非常簡單，對業(yè)務代碼沒有侵入性。

不足的地方是目前文檔比較少，網(wǎng)上的相關(guān)材料也不是很多，所以使用過程中遇到問題時可能就需要自己查看源碼，分析原理。

Seata 還支持 TCC 和 Saga 模式，但支持的主要方式是 AT。

寫在最后

歡迎大家關(guān)注我的公眾號【風平浪靜如碼】，海量Java相關(guān)文章，學習資料都會在里面更新，整理的資料也會放在里面。

覺得寫的還不錯的就點個贊，加個關(guān)注唄！點關(guān)注，不迷路，持續(xù)更新！！！

總結(jié)

以上是生活随笔為你收集整理的快速了解阿里微服务热门开源分布式事务框架——Seata的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。