AT 模式

前提​

  • 基于支持本地 ACID 事务的关系型数据库。

  • Java 应用，通过 JDBC 访问数据库。

整体机制

  • 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

  • 二阶段：

    • 提交异步化，非常快速地完成。

    • 回滚通过一阶段的回滚日志进行反向补偿。

写隔离

  • 一阶段本地事务提交前，需要确保先拿到全局锁 。

  • 拿不到全局锁 ，不能提交本地事务。

  • 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

示例

两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

  1. tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。

  2. tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，但在 tx1 全局提交前，该记录的全局锁会一直被 tx1 持有，tx2 需要重试等待全局锁。

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

Write-Isolation: Commit

如果 tx1 的二阶段是全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。此时，如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。

分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃获取全局锁并回滚本地事务释放本地锁，最终 tx1 的分支回滚最终成功。

Write-Isolation: Rollback

在上述整个过程中全局锁在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。

读隔离

在数据库本地事务隔离级别读已提交（Read Committed）或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted）。

如果应用在特定场景下，必需要求全局的读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

Read Isolation: SELECT FOR UPDATE

SELECT FOR UPDATE 语句的执行会申请全局锁 ，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到拿到全局锁，即读取的相关数据是已提交的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句进行了代理。

工作机制

以一个示例来说明整个 AT 分支的工作过程。

业务表：product

Field
Type
Key

id

bigint(20)

PRI

name

varchar(100)

since

varchar(100)

AT 分支事务的业务逻辑：

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

一阶段​

过程：

  1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息。

  2. 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

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

得到前镜像：

id
name
since

1

TXC

2014

  1. 执行业务 SQL：更新这条记录的 name 为 'GTS'。

  2. 查询后镜像：根据前镜像的结果，通过主键定位数据。

select id, name, since from product where id = 1;

得到后镜像：

id
name
since

1

GTS

2014

  1. 插入回滚日志：把前后镜像数据以及业务 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"
}

  1. 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的全局锁。

  2. 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。

  3. 将本地事务提交的结果上报给 TC。

二阶段-回滚​

收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。

  1. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。

  2. 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。

  3. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

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

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

二阶段-提交​

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

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

附录

回滚日志表​

UNDO_LOG：不同数据库在类型上会略有差别。

以 MySQL 为例：

Field
Type

branch_id

bigint PK

xid

varchar(100)

context

varchar(128)

rollback_info

longblob

log_status

tinyint

log_created

datetime

log_modified

datetime

-- 注意此处 0.7.0+ 增加字段 context
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,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
Previous分布式事务中间件 SeataNextTCC 模式

Last updated