seata的AT模式原理

最新推荐文章于 2024-08-30 18:28:49 发布

阮空空

最新推荐文章于 2024-08-30 18:28:49 发布

阅读量4.5k

点赞数 2

分类专栏： JAVA 经验文章标签： java 分布式阿里云

本文链接：https://blog.csdn.net/RuanEmpty/article/details/126340169

版权

JAVA 同时被 2 个专栏收录

12 篇文章 1 订阅

订阅专栏

经验

3 篇文章 0 订阅

订阅专栏

seata的AT模式原理

1. 定义

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

2.系统组成

在这里插入图片描述
Seata有三个核心组件：

Transaction Coordinator(TC，事务协调器)
维护全局事务和分支事务的状态，驱动全局事务提交或回滚。
Transaction Manager(TM，事务管理器)
定义全局事务的范围，开始事务、提交事务、回滚事务。
Resource Manager(RM，资源管理器)
管理分支事务上的资源，向TC注册分支事务，汇报分支事务状态，驱动分支事务的提交或回滚。

三个组件相互协作，TC 以 Server 形式独立部署，TM和RM集成在应用中启动，其整体交互如下：
在这里插入图片描述

3.AT模式

AT对业务代码完全无侵入性，使用非常简单，改造成本低。我们只需要关注自己的业务SQL，Seata会通过分析我们业务SQL，反向生成回滚数据。

3.1前提

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

3.2整体机制

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

3.3整体机制详解

一阶段：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

在这里插入图片描述
二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库，所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

在这里插入图片描述
二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

在这里插入图片描述

3.4.写隔离

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

两个全局事务 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 持有的，所以不会发生脏写的问题。

3.5.读隔离

在数据库本地事务隔离级别读已提交（Read Committed）或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted）。
如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
在这里插入图片描述
SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。
出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

3.6.特点

优点：对代码无侵入；并发度高，本地锁在一阶段就会释放；不需要数据库对XA协议的支持。
缺点：只能用在支持ACID的关系型数据库；SQL解析还不能支持全部语法。

3.7.AT 模式核心实现

鉴于Seata支持的模式较多，而其默认的模式是AT，为节省篇幅，以下围绕AT模式分析其相关的核心模块实现。

1. 事务协调器的启动

TC（事务协调器）以独立的服务启动，作为Server，维护全局事务和分支事务的状态，驱动全局事务提交或回滚。下面是TC的启动流程：
在这里插入图片描述

2. 事务管理器的启动

TM（事务管理器）集成在应用中启动，负责定义全局事务的范围，开始事务、提交事务、回滚事务。
TM所在应用中需要配置GlobalTransactionScannerbean，在应用启动时会进行如下初始化流程：
在这里插入图片描述

3. 资源管理器的启动

RM（资源管理器）集成在应用中启动，负责管理分支事务上的资源，向TC注册分支事务，汇报分支事务状态，驱动分支事务的提交或回滚。
RM所在的应用中除了需要跟TM一样配置GlobalTransactionScanner以启动RMClient，还需要配置DataSourceProxy，以实现对数据源访问代理。该数据源代理实现了sql的解析 → 生成undo-log → 业务sql和undo-log一并本地提交等操作。

4. 全局事务的工作流程

下面以一个简单的例子来说明全局事务的工作原理：

BusinessService：发起购买服务
StorageService：库存管理服务

购买操作实现在businessService.purchase中，purchase方法实现上通过GlobalTransaction注解，通过Dubbo服务，调用了库存服务deduct方法方法，样例如下：

@GlobalTransactional(timeoutMills = 300000, name = "dubbo-demo-tx")public void purchase(String userId, String commodityCode, int orderCount) {
    storageService.deduct(commodityCode, orderCount);
    // throw new RuntimeException("xxx");}

4.1 成功的全局事务处理流程

在这里插入图片描述

4.2 异常的全局事务处理流程

在这里插入图片描述

5. 写隔离实现

全局事务未提交，分支事务本地已经提交的情况下（假设修改了资源A），如何避免其他事务在此时修改资源A？
Seata采用全局锁来实现，其流程如下：
在这里插入图片描述

3.8.总结

Seata是Java领域很强大的分布式事务框架，其支持了多种模式。其中默认支持的AT模式，相比于传统的2PC协议（基于数据库的XA协议），很好地解决了2PC长期锁资源的问题，提高了并发度。Seata支持的各个模式中，AT模式对业务零入侵实现分布式事务，对于开发者更加友好。另外Seata的Server在选择合适的存储介质时可以进行集群模式，减少单点故障影响。