【深入淺出Seata原理及實戰】「入門基礎專題」探索Seata服務的AT模式下的分散式開發實戰指南（2）

洛神灬殤發表於2023-01-13
模式分散式

承接上文

上一篇文章說到了Seata 為使用者提供了 AT、TCC、SAGA 和 XA 事務模式，為使用者打造一站式的分散式解決方案。那麼接下來我們將要針對於AT模式下進行分散式事務開發的原理進行介紹以及實戰。

Seata AT模式

在AT、TCC、SAGA 和 XA 這四種事務模式中使用最多，最方便的就是 AT 模式。與其他事務模式相比，AT 模式可以應對大多數的業務場景，且基本可以做到無業務入侵，開發人員能夠有更多的精力關注於業務邏輯開發。

使用AT模式的前提

任何應用想要使用Seata的 AT 模式對分散式事務進行控制，必須滿足以下 2 個前提：

  1. 必須使用支援本地 ACID 事務特性的關係型資料庫，例如 MySQL、Oracle 等；
  2. 應用程式必須是使用 JDBC 對資料庫進行訪問的 JAVA 應用。

Seata安裝使用

下載地址

Seata服務進行下載的地址：https://seata.io/zh-cn/blog/download.html，訪問之後可以看到下面的資源中，可以直接進行下載，如下圖所示。

但是由於官方維護的稍微緩慢，所以並不是最新的版本，如果你想要下載較新的版本，可以去官方的Git倉庫中進行下載對應的版本檔案包。地址為：https://github.com/seata/seata/releases，可以看到下面的最新版本已經到了1.6.1了

我們選擇下載對應的可執行包即可。

建立UNDO_LOG表

SEATA AT模式需要針對業務中涉及的各個資料庫表，分別建立一個UNDO_LOG（回滾日誌）表。不同資料庫在建立 UNDO_LOG 表時會略有不同，以 MySQL 為例，其 UNDO_LOG 表的創表語句如下：

-- 注意此處0.3.0+ 增加唯一索引 ux_undo_log
CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  `ext` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

啟動服務

下載伺服器軟體包後，將其解壓縮。主要透過指令碼進行啟動Seata服務

Seata Server 目錄中包含以下子目錄：

  • bin：用於存放Seata Server可執行命令。
  • conf：用於存放Seata Server的配置檔案。
  • lib：用於存放Seata Server依賴的各種 Jar 包。
  • logs：用於存放Seata Server的日誌。

Seata Server的執行指令碼

  • seata-server.sh：主要是為Linux和Mac系統準備的啟動指令碼。執行sh seata-server.sh啟動服務。
  • seata-server.bat：主要是為Windows系統準備的啟動指令碼。執行cmd seata-server.bat啟動服務。

其中引數的選擇範圍如下所示

--host, -h（簡略指令）該地址向註冊中心公開，其他服務可以透過該ip訪問seata-server，預設: 0.0.0.0
--port, -p（簡略指令） 監聽的埠，預設值為8091
--storeMode, -m（簡略指令）日誌儲存模式 : file（檔案）、db（資料庫），預設為：file
--help 幫助指令

例如執行shell指令碼

sh seata-server.sh -p 8091 -h 127.0.0.1 -m file

AT 模式的工作機制

Seata的AT模式工作時大致可以分為以兩個階段，下面我們就結合一個例項來對 AT 模式的工作機制進行介紹。

整體機制

兩階段提交協議的演變：

  • 一階段：業務資料和回滾日誌記錄在同一個本地事務中提交，釋放本地鎖和連線資源。
  • 二階段：提交非同步化，非常快速地完成。回滾透過一階段的回滾日誌進行反向補償。
AT模式一階段

Seata AT模式一階段的工作流程如下圖所示

業務資料和回滾日誌記錄在同一個本地事務中提交，釋放本地鎖和連線資源。

第一子階段-獲取SQL的基本資訊

Seata攔截並解析業務SQL，得到SQL 的操作型別（INSERT/UPDATE/DELETE）、表名（tableXXX）、判斷條件（where condition = value）等相關資訊。

第二子階段-查詢並備份【執行之前】的資料快照

根據得到的業務SQL資訊，生成“前映象查詢語句”。

select  *  from tableXX where condition=value;

執行“前映象查詢語句”，得到即將執行操作的資料，並將其儲存為“前映象資料（beforeImage）”。

第三子階段-執行業務操作的SQL語句

執行業務SQL，例如（update tableXX set parameter = 'value' where condition = value;），將這條記錄的進行修改。

第四子階段-查詢業務操作之後的資料，並且儲存下來

查詢後映象：根據“前映象資料”的主鍵（id : X），生成“後映象查詢語句”。

select  *  from tableXX where condition=value;

執行“後映象查詢語句”，得到執行業務操作後的資料，並將其儲存為“後映象資料（afterImage）”。

第五子階段-插入儲存回滾日誌記錄到undo_log表中

將前後映象資料和業務SQL的資訊組成一條回滾日誌記錄，插入到 UNDO_LOG 表中，示例回滾日誌如下。

{
	"branchId": 641789253,
	"undoItems": [{
		"afterImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "GTS"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"beforeImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "TXC"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"sqlType": "UPDATE"
	}],
	"xid": "xid:xxx"
}
提交前需要獲取申請本地鎖
  • 提交前，向TC註冊分支：申請TableXXX表中，id主鍵等於N的記錄的全域性鎖 。需要確保先拿到全域性鎖 。
    • 拿不到全域性鎖 ，不能提交本地事務。
    • 拿到全域性鎖，會被限制在一定範圍內，超出範圍將放棄，並回滾本地事務，釋放本地鎖。
示例說明：

兩個全域性事務tx1和tx2，分別對a表的m欄位進行更新操作，m的初始值1000。

  1. tx1先開始，開啟本地事務，拿到本地鎖，更新操作 m = 1000 - 100 = 900。本地事務提交前，先拿到該記錄的全域性鎖 ，本地提交釋放本地鎖。

  2. tx2後開始，開啟本地事務，拿到本地鎖，更新操作 m = 900 - 100 = 800。本地事務提交前，嘗試拿該記錄的全域性鎖 ，tx1 全域性提交前，該記錄的全域性鎖被 tx1 持有，tx2需要重試等待 全域性鎖 。

  1. tx1二階段全域性提交，釋放全域性鎖 。tx2 拿到全域性鎖提交本地事務

  2. 如果tx1的二階段全域性回滾，則tx1需要重新獲取該資料的本地鎖，進行反向補償的更新操作，實現分支的回滾。

此時，如果tx2仍在等待該資料的全域性鎖，同時持有本地鎖，則tx1的分支回滾會失敗。分支的回滾會一直重試，直到tx2的全域性鎖等鎖超時，放棄全域性鎖並回滾本地事務釋放本地鎖，tx1 的分支回滾最終成功。因為整個過程全域性鎖在tx1結束前一直是被tx1持有的，所以不會發生髒寫的問題。

資料庫隔離級別

在資料庫本地事務隔離級別，讀已提交（Read Committed）或以上的基礎上，Seata（AT 模式）的預設全域性隔離級別是讀未提交（Read Uncommitted） 。

如果應用在特定場景下，必需要求全域性的讀已提交 ，目前Seata的方式是透過 SELECT FOR UPDATE 語句的代理。

SELECT FOR UPDATE 語句的執行會申請全域性鎖 ，如果全域性鎖被其他事務持有，則釋放本地鎖（回滾 SELECT FOR UPDATE 語句的本地執行）並重試。這個過程中，查詢是被 block 住的，直到全域性鎖拿到，即讀取的相關資料是已提交的，才返回。

出於總體效能上的考慮，Seata目前的方案並沒有對所有 SELECT 語句都進行代理，僅針對 FOR UPDATE 的 SELECT 語句。

本地事務提交

業務資料的更新和前面步驟中生成的UNDO LOG一併提交，將本地事務提交的結果上報給TC。

AT模式二階段-回滾操作

  1. 收到TC的分支回滾請求，開啟一個本地事務。

  2. 透過XID和Branch ID查詢到相應的UNDO LOG 記錄。

  3. 資料校驗：拿 UNDO LOG 中的後鏡與當前資料進行比較，如果有不同，說明資料被當前全域性事務之外的動作做了修改。這種情況，需要根據配置策略來做處理，詳細的說明在另外的文件中介紹。

  4. 根據 UNDO LOG 中的前映象和業務SQL的相關資訊生成並執行回滾的語句：

update TableXXX set parameter = 'XXX' where condition = value;
  1. 提交本地事務，並把本地事務的執行結果（即分支事務回滾的結果）上報給 TC。
AT模式二階段-提交操作

  1. 收到TC的分支提交請求，把請求放入一個非同步任務的佇列中，馬上返回提交成功的結果給 TC。

  2. 非同步任務階段的分支提交請求將非同步和批次地刪除相應 UNDO LOG 記錄。

相關文章