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

阿里开源分布式事务一站式解决方案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协议占用数据库资源时间长问题针对性的设计：

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。

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

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

写隔离

写隔离特点：

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

举栗说明

官方示例如下：

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

、

正常情况下：

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

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

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

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

读隔离

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

一阶段

过程：

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

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

得到前镜像：

id	name	since
1	TXC	2014

执行业务 SQL：更新这条记录的 name 为 'GTS'。
查询后镜像：根据前镜像的结果，通过主键定位数据。

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

得到后镜像：

id	name	since
1	GTS	2014

插入回滚日志：把前后镜像数据以及业务 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 一并提交。
将本地事务提交的结果上报给 TC。

二阶段-回滚

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

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

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

二阶段-提交

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

分布式事务解决方案Seata——AT模式详解相关推荐

分布式事务解决方案Seata
一.Seata 简介 Seata 是阿里巴巴2019年开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务.在 Seata 开源之前,Seata 对应的内部版本在阿里内 ...
分布式事务(Seata) 四大模式详解
前言在上一节中我们讲解了,关于分布式事务和seata的基本介绍和使用,感兴趣的小伙伴可以回顾一下<别再说你不知道分布式事务了!> 最后小农也说了,下期会带给大家关于Seata中关于sea ...
druid seata 配置_分布式事务解决方案——Seata使用
在微服务开发过程中分布式事务一直是一个比较重要的问题,之前对于分布式事务的解决方法一般会通过MQ的最终一致性来解决,尤其是RocketMQ的事务消息,感兴趣的可以看Spring Boot整合Rocke ...
微服务分布式事务解决方案Seata
文章目录一.Seata是什么? 二.使用步骤 1.引入库 2.读入数据总结一.什么是Seata? Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务.Sea ...
还不会分布式事务，seata xa模式入门实战送上
文章目录前言一.什么是seata? 二.seata原理说明 1.角色说明 2.什么是 Seata 的事务模式? 三.SEATA 的分布式案例 1.业务逻辑说明 2.架构图 3.SEATA 的分布式 ...
seata 集群_【视频】聊聊分布式事务解决方案seata
什么seata Seata 是一款开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务.在 Seata 开源之前,Seata 对应的内部版本在阿里经济体内部一直扮演着分布 ...
从一笔金币充值去思考分布式事务，五种方案详解！
小Hub领读: 分布式事务,有很多种解决方案,你知道啥场景用哪种解决方案吗?有啥优势?瞧瞧这篇文章! 作者:郑郑好victorzheng 原文地址 https://juejin.im/post/5ba ...
阿里分布式事务框架Seata,AT模式原理解析
什么是分布式事务如今在分布式技术盛行下,许多公司都已经在使用分布式技术了,虽然分布式技术给我们项目带来了三高(高可用,高扩展,高性能)等优点,但是缺点也很明显,分布式项目一般都是分服务开发,且多个服 ...
saga模式、Seata saga模式详解
文章目录一.前言二.SAGA模式 0.saga论文摘要 1.什么是长事务? 2.saga的组成 3.saga的两种执行场景 1)forward recovery 2)backward recove ...

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

概述

Seata AT模式

写隔离

读隔离

工作机制

一阶段

二阶段-回滚

二阶段-提交

分布式事务解决方案Seata——AT模式详解相关推荐

最新文章

热门文章