深入浅出Seata原理及实战「入门基础专题」探索Seata服务的AT模式下的分布式开发实战指南

Posted 2023-01-11 洛神灬殇

承接上文

上一篇文章说到了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需要重试等待 全局锁 。

3. tx1二阶段全局提交，释放全局锁 。tx2 拿到全局锁提交本地事务
   

4. 如果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;

5. 提交本地事务，并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

AT模式二阶段-提交操作

1. 收到TC的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。

2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。