【Seata】理解什么是AT、TCC、Saga以及本地锁、全局锁、seata的事务级别

云川之下

已于 2022-05-17 17:25:35 修改

阅读量4.6k

点赞数 9

文章标签： seata 全局锁本地锁事务级别

于 2021-11-17 16:21:35 首次发布

本文链接：https://blog.csdn.net/m0_45406092/article/details/121263208

版权

文章目录

概述
1. Seata 是什么?
2. AT 模式
3 .AT模式工作机制
参考

概述

先阅读【mysql】MySQL事务隔离级别详解（附带实例）了解事务隔离级，默认的事务隔离级是可重复读（REPEATABLE READ）级别，一般情况下，读写都是有保障了。

seata的AT模式依赖本地锁和全局锁实现隔离，因此默认的隔离级别有所不同：

分支事务通过本地锁实现了隔离，隔离级别为读已提交，即开启事务A的分支事务a1获得本地锁，一旦提交分支事务，就释放本地锁，别的事务就可以读到a1的数据，后面还有有其他的分支事务，例如a2、a3等；

此时，别的事务B可以读到脏数据(如果a1后来回滚的话，B读到的就是脏数据，如果a1不回滚，就没问题)
全局事务层面来看，级别是读未提交，即分支事务存在回滚情况，存在脏读情况；由于全局锁机制，可以保证写写安全

其他事务的写操作不会有问题，因为有全局锁！总结为一个写一个读，不冲突，但存在脏读；一个写，另一个也写，会冲突！

什么是全局锁？全局锁其实就是一个普通表，我们称之为全局表，记录了事务A的分支事务a1、a2、a3涉及的表和该表的行，假设是表1的 2、4行，那么其他事务B去修改表1的第5行时，需要去全局表检查下第五行是否已存在，这里是不存在的，即事务B和A不冲突，假设B尝试修改表1的第2行，那么就冲突了，禁止提交，直至事务A释放全局锁。

注意：读和写的区别，读一般不受控制，可能存在脏读(可以强制加锁，来确保读的正确性)，但是写写操作，一定由全局锁控制，避免冲突

1. Seata 是什么?

更多说明图，参见概览

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

2. AT 模式

2.1 前提

基于支持本地 ACID 事务的关系型数据库。
Java 应用，通过 JDBC 访问数据库。

2.2 整体机制

两阶段提交协议的演变：

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

二阶段：

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

2.3 写隔离

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

以一个示例来说明：

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

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。

本地锁是如何拿到的？参见【Seata】如何获取本地锁。简单来说会执行带有for update的语句，这样本地事务就会持有本地锁，直至本地事务提交后才会释放本地锁。

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

在这里插入图片描述
tx1 二阶段全局提交(Global commit指二阶段提交)，释放全局锁。tx2 拿到全局锁提交本地事务。

总结：

本地锁是DataSourceProxy代理封装sql，改为for update获取的，本地事务一旦提交，自动释放本地锁
全局锁是获取第一个分支事务id生成的，知道整个全局事务结束，才会释放全局锁

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚：
在这里插入图片描述
此时，如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

这里面的细节是等待本地锁不会超时，而全局锁会超时，因此，优先让回滚操作执行。

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

2.4 读隔离

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

本地事务是读已提交，在哪设置的？

本地事务是读已提交，每个本地事务对应一个分支事务，如果存在1个全局事务,global_tx1和非全局事务tx2，假设global_tx1的分支事务branch_txt1 已经发生本地事务提交(例如库存=10，提交前是11)，此时tx2的可以读到库存=10，然后global_tx1发生回滚，库存=11，此时，tx2就发生了脏读情况。

如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
在这里插入图片描述
SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。

如果查询的sql包含for update，那么代理就会添加全局锁逻辑。
此时，会不断的等待全局锁，如果tx2拿到了全局锁，表明tx1释放全局锁，并且该全局事务已经完成，那么就避免了脏读

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

3 .AT模式工作机制

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

业务表：product
在这里插入图片描述
AT 分支事务的业务逻辑：

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

3.1 一阶段

过程：

解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

得到前镜像：
执行业务 SQL：更新这条记录的 name 为 ‘GTS’。

注意：虽然执行了sql，但是本地事务未提交，通过数据库工具是查不到该数据的
查询后镜像：根据前镜像的结果，通过主键定位数据。
```
select id, name, since from product where id = 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"
}

提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的全局锁。
本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。

注意：本地事务真正提交了，通过数据库工具是可以查到该数据的，包括用户数据和Undo表的数据
将本地事务提交的结果上报给 TC。

3.2 二阶段-提交

收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
疑问，tc何时通知提交？应用有前提条件，即tm必须告知tc所有的分支事务都执行完了，否则tc哪知道还有没有其他分支事务需要执行？
异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

3.3 二阶段-回滚

收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
疑问，tc何时通知回滚提交？这个比较简单，只要任意的一个分支事务发生异常，那么就会触发回滚
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：
```
update product set name = 'TXC' where id = 1;
```
提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。