SpringCloud - Spring Cloud Alibaba 之 Seata分布式事务服务;AT事务模式机制,读写隔离(二十一)
Posted MinggeQingchun
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SpringCloud - Spring Cloud Alibaba 之 Seata分布式事务服务;AT事务模式机制,读写隔离(二十一)相关的知识,希望对你有一定的参考价值。
阅读本文前可先参考:
SpringCloud - Spring Cloud Alibaba 之 Seata分布式事务服务详解;部署(十八)_MinggeQingchun的博客-CSDN博客
https://blog.csdn.net/MinggeQingchun/article/details/126176893
https://blog.csdn.net/MinggeQingchun/article/details/126153368
以下全部转载自Seata官网
AT 模式
前提:
1、基于支持本地 ACID 事务的关系型数据库
2、Java 应用,通过 JDBC 访问数据库
整体机制
两阶段提交协议的演变:
一阶段:
业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源(本地事务,就已经在数据库持久化了)
二阶段:
1、没有异常
提交异步化,非常快速地完成(正常情况,就提交了,同步一下TC Server的状态,删除回滚日志)
2、有异常
回滚,通过一阶段的回滚日志进行反向补偿(如订单删除,库存加回去,余额加回去)
一、AT事务模式分布式事务工作机制
以一个示例来说明整个 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 语句
以上是关于SpringCloud - Spring Cloud Alibaba 之 Seata分布式事务服务;AT事务模式机制,读写隔离(二十一)的主要内容,如果未能解决你的问题,请参考以下文章
Spring Cloud总结29.Zuul的FallBack回退机制
Oauth2.0 整合springCloud的Zuul 解决关键BUG 报错信息:Principal must not be null
Spring Cloud Alibaba - 02 SpringCloud SpringCloud Alibaba SpringBoot的生产版本选择