1. Seata 概述

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

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

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

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

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

Seata 如何處理呢？

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

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

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

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

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

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

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

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

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

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

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

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

重要機制

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

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

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

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

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

(2)RM 是怎么自動和 TC 交互的？

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

(3)二階段回滾失敗怎么辦？

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

1.3 核心組件

回顧一下其中的核心組件：事務(wù)協(xié)調(diào)器 TC

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

開啟、提交或者回滾一個全局事務(wù)。資源管理者 RM

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

1.4 具體工作過程

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

TM 請求 TC，開始一個新的全局事務(wù)，TC 會為這個全局事務(wù)生成一個 XID。

XID 通過微服務(wù)的調(diào)用鏈傳遞到其他微服務(wù)。

RM 把本地事務(wù)作為這個XID的分支事務(wù)注冊到TC。

TM 請求 TC 對這個 XID 進行提交或回滾。

TC 指揮這個 XID 下面的所有分支事務(wù)進行提交、回滾。

2. Seata 詳細工作流程示例

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

例如有一個業(yè)務(wù)表 product(id,name)，分支事務(wù)的業(yè)務(wù)邏輯：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';

得到前鏡像：

(3)執(zhí)行業(yè)務(wù) SQL

執(zhí)行自己的業(yè)務(wù)邏輯：update product set name = 'GTS' where name = 'TXC';

把 name 改為了 GTS。

(4)查詢后鏡像

根據(jù)前鏡像的結(jié)果，通過 主鍵 定位數(shù)據(jù)。select id, name from product where id = 1;

得到后鏡像：

(5)插入回滾日志

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

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

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

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

2.2 二階段 - 回滾

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

(2)通過 XID 和 Branch ID 查找到相應(yīng)的 UNDO LOG 記錄。

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

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

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

(5)提交本地事務(wù)

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

二階段 - 提交

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

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

3. 小結(jié)

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

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

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

總結(jié)

以上是生活随笔為你收集整理的seata xid是什么_阿里开源的分布式事务框架 Seata的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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