博客

SpringCloud – Spring Cloud Alibaba 之 Seata分布式事务服务；AT事务模式机制，读写隔离（二十一）

  • Post author:
  • Post category:其他


阅读本文前可先参考：


SpringCloud – Spring Cloud Alibaba 之 Seata分布式事务服务详解；部署（十八）_MinggeQingchun的博客-CSDN博客


https://blog.csdn.net/MinggeQingchun/article/details/126176893


https://blog.csdn.net/MinggeQingchun/article/details/126153368

以下全部转载自Seata官网


Seata 是什么

AT 模式


Seata 是什么

前提：

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

2、Java 应用，通过 JDBC 访问数据库

整体机制

两阶段提交协议的演变：


一阶段

：

业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源（本地事务，就已经在数据库持久化了）


二阶段：

1、没有异常

提交异步化，非常快速地完成（正常情况，就提交了，同步一下TC Server的状态，删除回滚日志）

2、有异常

回滚，通过一阶段的回滚日志进行反向补偿（如订单删除，库存加回去，余额加回去）

一、AT事务模式分布式事务工作机制


Seata 是什么

以一个示例来说明整个 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

3、执行业务 SQL：更新这条记录的 name 为 ‘GTS’

4、查询后镜像：根据前镜像的结果，通过

主键

定位数据。 

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

得到后镜像：

id name since
1 GTS 2014

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

6、提交前，向 TC 注册分支：申请

product

表中，主键值等于 1 的记录的

全局锁

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

8、将本地事务提交的结果上报给 TC

二阶段-回滚

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

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

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

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

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

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

二阶段-提交

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

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

二、读写隔离



写隔离


1、一阶段本地事务提交前，需要确保先拿到

全局锁

；

2、拿不到

全局锁

，不能提交本地事务；

3、拿

全局锁

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

以一个示例来说明：



两个


或者多个全局事务 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 语句