分布式事务解决方案Seata——AT模式详解

需要了解分布式事务的同学可以关注我的专栏一起学习，欢迎沟通：分布式事务

阿里开源分布式事务一站式解决方案seata基础认识可参见：分布式事务2PC协议之——Seata方案基本认识

概述

在我的另一篇关于seata方案的基本认识中我们了解到seata方案支持如下四种事务模式：

• AT
• TCC
• SAGA 
• XA 

其中XA模式有较为明显的缺陷（锁定数据库资源时间长，需要本地数据库支持XA协议），较为常见的就是AT模式和TCC模式，SAGA模式由于其点特分明，需要谨慎使用。本文主要介绍一下较为经典的AT模式。

Seata AT模式

AT模式，其实就是Seata对XA模式的完美理想实现，其最低满足要求如下：

• 支持本地ACID（Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 持久性）事务的关系型数据库，无需数据库支持XA协议

• Java应用，JDBC方式连接数据库

对于这两点要求来说，其实不算是什么要求，简直是阿里为目前行业定制的分布式事务解决方案。目前开源的分布式框架springcloud使用率很高，springcloud alibaba阿里也在积极的推广，这是Java分布式系统的温床，市面上使用最多的数据库有Oracle和MySQL，这么多现成的条件对于开发者和公司技术选型目标瞄向Seata是一种巨大的推动。

AT模式是XA协议的完美理想实现！也就是说AT模式也满足两阶段提交协议——2PC（关于2PC的介绍可以参考我的另一篇文章：分布式事务解决方案——2PC（两阶段提交）概念），但是！AT模式的两阶段提交协议是优化过的，是对XA协议占用数据库资源时间长问题针对性的设计：

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

• 二阶段：

  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

简单的理解就是如下两点：

1. XA协议在全局事务提交之前，所有分支事务都是未提交状态的，而Seata AT模式在第一阶段完成各分支事务的数据操作后会提交本地事务，释放本地锁和数据资源
2. XA协议依靠分支事务的执行结果，来判断是否提交各个参与者的本地事务，还是回滚各个参与者的本地事务。由于AT模式是在各个参与者操作数据以及提交事务持久化数据之前，首先记录操作前的数据镜像，待数据操作完成提交事务之后再次记录修改后的数据镜像，通过这两个数据镜像在TC通知各个分支事务回滚时，进行数据的逆向操作达到回滚的目的。

写隔离

写隔离特点：

• 一阶段本地事务提交前，需要确保先拿到 全局锁 。
• 拿不到 全局锁 ，不能提交本地事务。
• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

举栗说明

官方示例如下：

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

、

正常情况下：

1. tx1对a表m字段操作，首先tx1需要获取本地锁
2. tx1持有本地锁，操作数据：m = m - 100
3. tx1在本地事务提交前，获取全局事务
4. tx1提交本地事务，数据持久化完成，释放本地锁。m = 900
5. tx2开启本地事务并获取本地锁
6. tx2持有本地所，操作数据：m = m - 100
7. tx2在提交本地事务前，尝试获取该条数据的全局锁，如果此时tx1还没有释放全局锁，tx2处于等待全局锁的状态
8. 如果tx1提交了本地事务，释放了全局锁，tx2获取全局锁成功
9. tx2提交本地事务，数据完成持久化 m = 800，释放本地锁
10. 最终执行结果由TC（Transaction Coordinator - 事务协调者）决策，释放全局锁，操作完毕

 

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

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

读隔离

1. tx1需要操作数据，获取本地锁
2. tx1持有本地锁，操作数据：m = m - 100
3. tx1在本地事务提交前，获取全局事务
4. tx1提交本地事务，数据持久化完成，释放本地锁。m = 900
5. 出现异常，TC（Transaction Coordinator - 事务协调者）在根据某个参与者的操作失败结果，通知全局开始回滚
6. 此时tx2获取本地锁，尝试使用select for update查询数据，尝试获取全局锁
7. 全局锁被tx1持有，tx2无法获取，select for update查询阻塞，等待全局锁被释放后执行
8. tx1回滚成功，m = 1000，数据都是提交状态（该数据没有处于update操作中），tx1释放全局锁
9. tx2获取全局锁，执行select for update

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

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

注意：MySQL默认事务隔离级别REPEATABLE-READ，Oracle默认事务隔离界别READ COMMITTED

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。

二阶段-回滚

1. 收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
3. 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍（根本找不到另外的文档，网上也搜不到合理的措施，唯一搜到的解决方法是手动处理......）。
4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

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

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

二阶段-提交

1. 收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。