Seata的基本使用

爬台阶的蚂蚁

已于 2024-04-25 10:17:40 修改

阅读量802

点赞数

分类专栏：微服务文章标签：学习 java spring cloud seata

于 2023-01-30 10:07:24 首次发布

本文链接：https://blog.csdn.net/qq_45003354/article/details/128796689

版权

微服务专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、Seata简介

1.简介： 提供分布式事务解决方案。用下图说明（图片取自Seata官网）
在这里插入图片描述
在我们的业务中经常会出现在一个微服务中需要操作其它几个微服务数据库的场景，怎么保证多个微服务各自操作数据库都成功或者失败，这个就是分布式事务需要解决的问题。
2.重要概念：

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务。
其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。

二、AT模型

1.概述：

AT 模式是 Seata 创新的一种非侵入式的分布式事务解决方案，Seata 在内部做了对数据库操作的代理层，我们使用 Seata AT 模式时，实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，比如插入回滚 undo_log 日志，检查全局锁等

2.整体机制

两阶段提交协议的演变：

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

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

3.工作机制

一阶段： 在这里插入图片描述

解析 SQL：得到 SQL 的类型（UPDATE/SELECT…），表（product/user/order…），条件等相关的信息
查询前镜像：根据解析得到的 条件信息，生成查询语句，定位数据
执行业务 SQL：更新这条记录
查询后镜像：根据前镜像的结果，通过主键定位数据
插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中
提交前，向 TC 注册分支：申请表中对应主键的 全局锁
本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交
将本地事务提交的结果上报给 TC

二阶段-回滚：
在这里插入图片描述

收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况没办法自动回滚可能需要人工介入处理。
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句
之后回滚sql后，删除uodo log日志
提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC

二阶段-提交：
在这里插入图片描述

收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
开启一个本地事务，执行如下操作
异步和批量地删除相应 UNDO LOG 记录。

4.基本使用

我们首先抽象一个使用场景，在用户购买行为的时候需要减少库存并减少账户余额，当库存表 stock_tbl 和 account_tbl 在同一个数据库时，我们可以使用关系数据库自身提供的能力非常容易实现事务。但如果这两个表分属于不同的数据源，我们就要使用 Seata 提供的分布式事务能力了。

@GlobalTransactional
public void purchase(String userId, String commodityCode, int count, int money) {
    jdbcTemplateA.update("update stock_tbl set count = count - ? where commodity_code = ?", new Object[] {count, commodityCode});
    jdbcTemplateB.update("update account_tbl set money = money - ? where user_id = ?", new Object[] {money, userId});
}

如果您曾使用过 Spring 框架 @Transactional 注解的话，也可以根据命名类比理解 @GlobalTransactional 的功能。是的，这里只是引入了一个注解就轻松实现了分布式事务能力，使用 AT 模式可以最小程度减少业务改造成本。

同时，需要注意的是，jdbcTemplateA 和 jdbcTemplateB 使用了不同的数据源进行构造，而这两个不同的数据源都需要使用 Seata 提供的 AT 数据源代理类 DataSourceProxy 进行包装。

三、TCC模型

1.概述：

TCC 模式是 Seata 支持的一种由业务方细粒度控制的侵入式分布式事务解决方案，是继 AT 模式后第二种支持的事务模式，最早由蚂蚁金服贡献。其分布式事务模型直接作用于服务层，不依赖底层数据库，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。

在这里插入图片描述

2.TCC简介

TCC 基于分布式事务中的二阶段提交协议实现，它的全称为 Try-Confirm-Cancel，即资源预留（Try）、确认操作（Confirm）、取消操作（Cancel）

3.重要概念：

Try：对业务资源的检查并预留；
Confirm：对业务处理进行提交，即 commit 操作，只要 Try 成功，那么该步骤一定成功；
Cancel：对业务处理进行取消，即回滚操作，该步骤回对 Try 预留的资源进行释放。

4.整体机制：

在两阶段提交协议中，资源管理器（RM, Resource Manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, Transaction Manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。

资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。

TCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态

5.基本使用：

public interface TccActionOne {
    @TwoPhaseBusinessAction(name = "DubboTccActionOne", commitMethod = "commit", rollbackMethod = "rollback")
    public boolean prepare(BusinessActionContext actionContext, @BusinessActionContextParameter(paramName = "a") String a);
    public boolean commit(BusinessActionContext actionContext);
    public boolean rollback(BusinessActionContext actionContext);
}

Seata 会把一个 TCC 接口当成一个 Resource，也叫 TCC Resource。在业务接口中核心的注解是 @TwoPhaseBusinessAction，表示当前方法使用 TCC 模式管理事务提交，并标明了 Try，Confirm，Cancel 三个阶段。name属性，给当前事务注册了一个全局唯一的的 TCC bean name。同时 TCC 模式的三个执行阶段分别是：

Try 阶段，预定操作资源（Prepare）这一阶段所以执行的方法便是被 @TwoPhaseBusinessAction 所修饰的方法。如示例代码中的 prepare 方法。
Confirm 阶段，执行主要业务逻辑（Commit）这一阶段使用 commitMethod 属性所指向的方法，来执行Confirm 的工作。
Cancel 阶段，事务回滚（Rollback）这一阶段使用 rollbackMethod 属性所指向的方法，来执行 Cancel 的工作。

其次，可以在 TCC 模式下使用 BusinessActionContext 在事务上下文中传递查询参数。如下属性：

xid 全局事务id
branchId 分支事务id
actionName 分支资源id，（resource id）
actionContext 业务传递的参数，可以通过 @BusinessActionContextParameter 来标注需要传递的参数。

在定义好 TCC 接口之后，我们可以像 AT 模式一样，通过 @GlobalTransactional 开启一个分布式事务。

@GlobalTransactional
public String doTransactionCommit(){
    tccActionOne.prepare(null,"one");
    tccActionTwo.prepare(null,"two");
}

注意，如果 TCC 参与者是本地 bean（非远程RPC服务），本地 TCC bean 还需要在接口定义中添加 @LocalTCC 注解，比如

@LocalTCC
public interface TccActionTwo {
    @TwoPhaseBusinessAction(name = "TccActionTwo", commitMethod = "commit", rollbackMethod = "rollback")
    public boolean prepare(BusinessActionContext actionContext, @BusinessActionContextParameter(paramName = "a") String a);
    public boolean commit(BusinessActionContext actionContext);
    public boolean rollback(BusinessActionContext actionContext);
}

6.TCC和AT的对比

相同点：

在Seata中，AT模式与TCC模式事实上都是两阶段提交的具体实现

不同点：

AT 模式基于支持本地 ACID 事务的关系型数据库：
一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
二阶段 commit 行为：马上成功结束，自动异步批量清理回滚日志。
二阶段 rollback 行为：通过回滚日志，自动生成补偿操作，完成数据回滚。
TCC 模式不依赖于底层数据资源的事务支持：
一阶段 prepare 行为：调用自定义的 prepare 逻辑。
二阶段 commit 行为：调用自定义的 commit 逻辑。
二阶段 rollback 行为：调用自定义的 rollback 逻辑。

总结：TCC就是纯手工的AT模式，它不会依赖于Undo log，两阶段的提交和回滚都需要自己实现业务逻辑。

7.TCC模式常见的问题及解决方案

7.1空回滚

即在执行try方法时由于网络等问题实际上没有执行，此时却需要执行cancel方法。

Seata 的做法是新增一个 TCC 事务控制表，包含事务的 XID 和 BranchID 信息，在 Try 方法执行时插入一条记录，表示一阶段执行了，执行 Cancel 方法时读取这条记录，如果记录不存在，说明 Try 方法没有执行，直接返回成功，不需要回滚操作。

7.2幂等

try方法执行成功后，在执行Confirm/Cancel时由于超时，实际上参与方已经执行完成，但是调用方会再次发起Confirm/Cancel。

在 TCC 事务控制表中增加一个记录状态的字段 status，该字段有 3 个值，分别为：
tried：1
committed：2
rollbacked：3
二阶段 Confirm/Cancel 方法执行后，将状态改为 committed 或 rollbacked 状态。当重复调用二阶段 Confirm/Cancel 方法时，判断事务状态即可解决幂等问题。

7.3悬挂

cancel方法在try方法之前执行，由于可以空回滚此时cancel返回成功，全局事务结束，此时后执行的try方法所预留的资源就无法被释放

在 TCC 事务控制表记录状态的字段 status 中增加一个状态：
suspended：4
当执行二阶段 Cancel 方法时，如果发现 TCC 事务控制表没有相关try方法记录，说明二阶段 Cancel 方法优先一阶段 Try 方法执行，因此插入一条 status=4 状态的记录，当一阶段 Try 方法后面执行时，判断 status=4 ，则说明有二阶段 Cancel 已执行，并返回 false 以阻止一阶段 Try 方法执行成功。

四、XA模型

1.概述

XA 模式是从 1.2 版本支持的事务模式。XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。

在这里插入图片描述

2.整体机制

执行阶段：
- 可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证可回滚
- 持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证持久化（即，之后任何意外都不会造成无法回滚的情况）
完成阶段：
- 分支提交：执行 XA 分支的 commit
- 分支回滚：执行 XA 分支的 rollback

3.基本使用

XA 模式使用起来与 AT 模式基本一致，用法上的唯一区别在于数据源代理的替换：使用 DataSourceProxyXA 来替代 DataSourceProxy。

public class DataSourceProxy {
    @Bean("dataSourceProxy")
    public DataSource dataSource(DruidDataSource druidDataSource) {
        // DataSourceProxyXA for XA mode
        return new DataSourceProxyXA(druidDataSource);
        // DataSourceProxy for AT mode
        // return new DataSourceProxy(druidDataSource);
    }
}

4.优缺点

优势
与 Seata 支持的其它事务模式不同，XA 协议要求事务资源本身提供对规范和协议的支持，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。此外的一些优势还包括：

业务无侵入：和 AT 一样，XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担。
数据库的支持广泛：XA 协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。
缺点
XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，性能差。