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

承接上文

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

Seata AT模式

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

使用AT模式的前提

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

必須使用支持本地 ACID 事務特性的關係型數據庫，例如 MySQL、Oracle 等；
應用程序必須是使用 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。

tx1先開始，開啓本地事務，拿到本地鎖，更新操作 m = 1000 - 100 = 900。本地事務提交前，先拿到該記錄的全局鎖，本地提交釋放本地鎖。
tx2後開始，開啓本地事務，拿到本地鎖，更新操作 m = 900 - 100 = 800。本地事務提交前，嘗試拿該記錄的全局鎖，tx1 全局提交前，該記錄的全局鎖被 tx1 持有，tx2需要重試等待全局鎖。

tx1二階段全局提交，釋放全局鎖。tx2 拿到全局鎖提交本地事務
如果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模式二階段-回滾操作

收到TC的分支回滾請求，開啓一個本地事務。
通過XID和Branch ID查找到相應的UNDO LOG 記錄。
數據校驗：拿 UNDO LOG 中的後鏡與當前數據進行比較，如果有不同，說明數據被當前全局事務之外的動作做了修改。這種情況，需要根據配置策略來做處理，詳細的說明在另外的文檔中介紹。
根據 UNDO LOG 中的前鏡像和業務SQL的相關信息生成並執行回滾的語句：

update TableXXX set parameter = 'XXX' where condition = value;

提交本地事務，並把本地事務的執行結果（即分支事務回滾的結果）上報給 TC。

AT模式二階段-提交操作

收到TC的分支提交請求，把請求放入一個異步任務的隊列中，馬上返回提交成功的結果給 TC。
異步任務階段的分支提交請求將異步和批量地刪除相應 UNDO LOG 記錄。