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

墨蓝 2023-09-28 18:54 115阅读 0赞

阅读本文前可先参考：

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

[https://blog.csdn.net/MinggeQingchun/article/details/126176893][https_blog.csdn.net_MinggeQingchun_article_details_126176893]

[https://blog.csdn.net/MinggeQingchun/article/details/126153368][https_blog.csdn.net_MinggeQingchun_article_details_126153368]

#### 以下全部转载自Seata官网 ####

[Seata 是什么][Seata]

##  ##

## AT 模式 ##

[Seata 是什么][Seata]

#### 前提： ####

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

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

#### 整体机制 ####

#### 两阶段提交协议的演变： ####

#### 一阶段： ####

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

#### 二阶段： ####

1、没有异常

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

2、有异常

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

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

[Seata 是什么][Seata]

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

业务表：**`product`**

<table> 
 <thead> 
  <tr> 
   <th>Field</th> 
   <th>Type</th> 
   <th>Key</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>id</td> 
   <td>bigint(20)</td> 
   <td>PRI</td> 
  </tr> 
  <tr> 
   <td>name</td> 
   <td>varchar(100)</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>since</td> 
   <td>varchar(100)</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

AT 分支事务的业务逻辑：

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

### 一阶段 ###

![250f36c92f4e44e5942f5f98ddc67830.png][]

过程：

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

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

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

得到前镜像：

<table> 
 <thead> 
  <tr> 
   <th>id</th> 
   <th>name</th> 
   <th>since</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>TXC</td> 
   <td>2014</td> 
  </tr> 
 </tbody> 
</table>

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

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

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

得到后镜像：

<table> 
 <thead> 
  <tr> 
   <th>id</th> 
   <th>name</th> 
   <th>since</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>GTS</td> 
   <td>2014</td> 
  </tr> 
 </tbody> 
</table>

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 需要重试等待 全局锁 ；

![af1f8b0525c4d0d2f23ed7ac9f40120a.png][]

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

![7e8362fe11488ee2867923801b55ac0f.png][]

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

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

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

### **读隔离** ###

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

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

![7291111de24523ccd1adda078eaba599.png][]

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

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

[SpringCloud - Spring Cloud Alibaba _ Seata_MinggeQingchun_-CSDN]: https://blog.csdn.net/MinggeQingchun/article/details/126100300
[https_blog.csdn.net_MinggeQingchun_article_details_126176893]: https://blog.csdn.net/MinggeQingchun/article/details/126176893
[https_blog.csdn.net_MinggeQingchun_article_details_126153368]: https://blog.csdn.net/MinggeQingchun/article/details/126153368
[Seata]: http://seata.io/zh-cn/docs/overview/what-is-seata.html
[250f36c92f4e44e5942f5f98ddc67830.png]: https://img-blog.csdnimg.cn/250f36c92f4e44e5942f5f98ddc67830.png
[af1f8b0525c4d0d2f23ed7ac9f40120a.png]: https://img-blog.csdnimg.cn/img_convert/af1f8b0525c4d0d2f23ed7ac9f40120a.png
[7e8362fe11488ee2867923801b55ac0f.png]: https://img-blog.csdnimg.cn/img_convert/7e8362fe11488ee2867923801b55ac0f.png
[7291111de24523ccd1adda078eaba599.png]: https://img-blog.csdnimg.cn/img_convert/7291111de24523ccd1adda078eaba599.png