【微服务架构】SpringCloud Alibaba（九）：分布式事务Seata使用和源码分析（TCC模式、Saga模式）

个人主页：道友老李
欢迎加入社区：道友老李的学习社区

SpringCloud Alibaba

Spring Cloud Alibaba是阿里巴巴提供的一站式微服务解决方案，是Spring Cloud体系中的一个重要分支，它将阿里巴巴在微服务领域的实践经验和开源技术进行了整合，为开发者提供了一系列便捷的工具和组件，用于构建分布式微服务应用。以下是其详细介绍：

1、核心组件

• Nacos：用于服务注册与发现以及配置管理。它可以帮助微服务实例自动注册到注册中心，并能够动态获取配置信息，使应用程序能够灵活地应对配置的变化，无需重启服务。
• Sentinel：主要用于流量控制、熔断降级等功能。它可以保护微服务免受高并发、流量异常等情况的影响，确保系统在压力下能够稳定运行，避免因个别服务出现问题而导致整个系统崩溃。
• RocketMQ：是一款高性能、高可靠的分布式消息队列。它在微服务架构中常用于实现异步消息传递、解耦系统组件之间的依赖关系，从而提高系统的整体性能和可扩展性。
• Seata：致力于提供分布式事务解决方案，确保在分布式系统中数据的一致性。它通过对事务的协调和管理，使得多个微服务之间在进行数据交互时能够遵循ACID原则。

2、优势

• 一站式解决方案：涵盖了微服务架构中的多个关键领域，包括服务治理、配置管理、流量控制、分布式事务等，开发者无需再从多个不同的开源项目中进行整合，大大降低了微服务架构的搭建和维护成本。
• 与Spring Cloud生态的深度集成：基于Spring Cloud的编程模型和规范进行开发，使得熟悉Spring Cloud的开发者能够快速上手并轻松集成到现有的Spring Cloud项目中，充分利用Spring Cloud的各种特性和优势。
• 阿里巴巴的技术实力和实践经验支持：得益于阿里巴巴在大规模分布式系统开发和运营方面的丰富经验，Spring Cloud Alibaba的组件经过了实际生产环境的考验，具有较高的稳定性、性能和可扩展性，能够应对各种复杂的业务场景和高并发流量。

3、应用场景

• 电商系统：在电商业务中，存在多个微服务，如商品服务、订单服务、库存服务等。Spring Cloud Alibaba可以通过Nacos进行服务注册与发现，使用Sentinel对各个服务的流量进行控制，利用RocketMQ实现异步消息通知，比如下单成功后异步通知库存服务扣减库存，通过Seata保证分布式事务的一致性，确保订单和库存等数据的准确性。
• 金融系统：金融领域对数据一致性和系统稳定性要求极高。Spring Cloud Alibaba的Seata可以确保在多个金融业务操作之间的分布式事务一致性，如转账操作涉及到两个不同账户服务之间的资金变动。Nacos可以提供配置管理，方便对金融业务的各种配置参数进行动态调整，Sentinel则可以防止因突发的高并发交易对系统造成冲击。
• 物联网（IoT）平台：物联网场景中，大量的设备会产生实时数据并上传到云端。Spring Cloud Alibaba可以通过Nacos管理各个物联网服务的注册与发现，使用RocketMQ接收和处理大量的设备数据消息，进行异步处理和分发。Sentinel可以对物联网服务的流量进行控制，防止因设备数据突发增长导致系统过载。

六、Seata

8、Seata TCC 模式设计思路

8.1 TCC 命名由来

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

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

TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的入侵性，设计相对复杂，但优点是 TCC 完全不依赖数据库，能够实现跨数据库、跨应用资源管理，对这些不同数据访问通过侵入式的编码方式实现一个原子操作，更好地解决了在各种复杂业务场景下的分布式事务问题。

8.2 执行流程

8.3 TCC和XA的区别

AT 模式基于 支持本地 ACID 事务 的 关系型数据库 ：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

简单点概括，SEATA的TCC模式就是手工的AT模式，它允许你自定义两阶段的处理逻辑而不依赖AT模式的undo_log。

8.4 TCC存在的问题

8.4.1 空回滚以及解决方案

空回滚指的是在一个分布式事务中，在没有调用参与方的 Try 方法的情况下，TM 驱动二阶段回滚调用了参与方的 Cancel 方法。

如上图所示，全局事务开启后，参与者 A 分支注册完成之后会执行参与者一阶段 RPC 方法，如果此时参与者 A 所在的机器发生宕机，网络异常，都会造成 RPC 调用失败，即参与者 A 一阶段方法未成功执行，但是此时全局事务已经开启，Seata 必须要推进到终态，在全局事务回滚时会调用参与者 A 的 Cancel 方法，从而造成空回滚。

要想防止空回滚，那么必须在 Cancel 方法中识别这是一个空回滚，Seata 是如何做的呢？

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

8.4.2幂等问题以及解决方案

幂等问题指的是 TC 重复进行二阶段提交，因此 Confirm/Cancel 接口需要支持幂等处理，即不会产生资源重复提交或者重复释放。

如上图所示，参与者 A 执行完二阶段之后，由于网络抖动或者宕机问题，会造成 TC 收不到参与者 A 执行二阶段的返回结果，TC 会重复发起调用，直到二阶段执行结果成功。

Seata 是如何处理幂等问题的呢？

同样的也是在 TCC 事务控制表中增加一个记录状态的字段 status，该字段有 3 个值，分别为：

1. tried：1
2. committed：2
3. rollbacked：3

二阶段 Confirm/Cancel 方法执行后，将状态改为 committed 或 rollbacked 状态。当重复调用二阶段 Confirm/Cancel 方法时，判断事务状态即可解决幂等问题。

8.4.3 悬挂问题以及解决方案

悬挂指的是二阶段 Cancel 方法比 一阶段 Try 方法优先执行，由于允许空回滚的原因，在执行完二阶段 Cancel 方法之后直接空回滚返回成功，此时全局事务已结束，但是由于 Try 方法随后执行，这就会造成一阶段 Try 方法预留的资源永远无法提交和释放了

如上图所示，在执行参与者 A 的一阶段 Try 方法时，出现网路拥堵，由于 Seata 全局事务有超时限制，执行 Try 方法超时后，TM 决议全局回滚，回滚完成后如果此时 RPC 请求才到达参与者 A，执行 Try 方法进行资源预留，从而造成悬挂。

Seata 是怎么处理悬挂的呢？

在 TCC 事务控制表记录状态的字段 status 中增加一个状态：

• suspended：4

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

8.5 Seata TCC模式的接口改造

假设现有一个业务需要同时使用服务 A 和服务 B 完成一个事务操作，我们在服务 A 定义该服务的一个 TCC 接口：

 public interface TccActionOne {
    // 业务处理
    @TwoPhaseBusinessAction(name = "TccActionOne", commitMethod = "commit", rollbackMethod = "rollback")
    public boolean prepare(BusinessActionContext actionContext, int a);

   // 提交 
    public boolean commit(BusinessActionContext actionContext);

   // 回滚
    public boolean rollback(BusinessActionContext actionContext);
}

同样，在服务 B 定义该服务的一个 TCC 接口：

 public interface TccActionTwo {
    // 业务处理
    @TwoPhaseBusinessAction(name = "TccActionTwo ", commitMethod = "commit", rollbackMethod = "rollback")
    public boolean prepare(BusinessActionContext actionContext, int a);

   // 提交 
    public boolean commit(BusinessActionContext actionContext);

   // 回滚
    public boolean rollback(BusinessActionContext actionContext);
}

在业务所在系统中开启全局事务并执行服务 A 和服务 B 的 TCC 预留资源方法：

@GlobalTransactional
public String doTransactionCommit(){
    //服务A事务参与者
    tccActionOne.prepare(null,"one");
    //服务B事务参与者
    tccActionTwo.prepare(null,"two");
}

以上就是使用 Seata TCC 模式实现一个全局事务的例子，TCC 模式同样使用 @GlobalTransactional 注解开启全局事务，而服务 A 和服务 B 的 TCC 接口为事务参与者，Seata 会把一个 TCC 接口当成一个 Resource，也叫 TCC Resource。

8.6 TCC 模式使用

业务场景：

用户下单，整个业务逻辑由三个微服务构成：

• 仓储服务：对给定的商品扣除库存数量。
• 订单服务：根据采购需求创建订单。
• 帐户服务：从用户帐户中扣除余额。

8.6.1 版本处理

Spring Cloud Alibaba Version	Spring Cloud Version	Spring Boot Version	Nacos Version	Seata Version
2.2.9.RELEASE	Hoxton.SR12	2.3.12.RELEASE	2.1.0	1.5.2

8.6.2 引入依赖

   <!--引入seata-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
        </dependency>

8.6.3 引入配置

seata:
  application-id: ${spring.application.name}
  # seata 服务分组，要与服务端配置service.vgroup_mapping的后缀对应
  tx-service-group: default_tx_group
  registry:
    # 指定nacos作为注册中心
    type: nacos
    nacos:
      application: seata-server
      server-addr: 127.0.0.1:8848
      namespace:
      group: SEATA_GROUP

  config:
    # 指定nacos作为配置中心
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: seata
      group: SEATA_GROUP
      data-id: seataServer.properties

8.6.4 定义TCC接口

TCC相关注解如下：

• @LocalTCC 适用于SpringCloud+Feign模式下的TCC，@LocalTCC一定需要注解在接口上，此接口可以是寻常的业务接口，只要实现了TCC的两阶段提交对应方法便可

• @TwoPhaseBusinessAction 注解try方法，其中name为当前tcc方法的bean名称，写方法名便可（全局唯一），commitMethod指向提交方法，rollbackMethod指向事务回滚方法。指定好三个方法之后，seata会根据全局事务的成功或失败，去帮我们自动调用提交方法或者回滚方法。

• @BusinessActionContextParameter 注解可以将参数传递到二阶段（commitMethod/rollbackMethod）的方法。

• BusinessActionContext 便是指TCC事务上下文

  @LocalTCC
  public interface TccOrderService {

  /**
   * TCC的try方法：保存订单信息，状态为支付中
   *
   * 定义两阶段提交，在try阶段通过@TwoPhaseBusinessAction注解定义了分支事务的 resourceId，commit和 cancel 方法
   *  name = 该tcc的bean名称,全局唯一
   *  commitMethod = commit 为二阶段确认方法
   *  rollbackMethod = rollback 为二阶段取消方法
   *  BusinessActionContextParameter注解 传递参数到二阶段中
   *  useTCCFence seata1.5.1的新特性，用于解决TCC幂等，悬挂，空回滚问题，需增加日志表tcc_fence_log
   */
  @TwoPhaseBusinessAction(name = "prepareSaveOrder", commitMethod = "commit", rollbackMethod = "rollback", useTCCFence = true)
  Order prepareSaveOrder(OrderVo orderVo, @BusinessActionContextParameter(paramName = "orderId") Long orderId);
  
  /**
   *
   * TCC的confirm方法：订单状态改为支付成功
   *
   * 二阶段确认方法可以另命名，但要保证与commitMethod一致
   * context可以传递try方法的参数
   *
   * @param actionContext
   * @return
   */
  boolean commit(BusinessActionContext actionContext);
  
  /**
   * TCC的cancel方法：订单状态改为支付失败
   * 二阶段取消方法可以另命名，但要保证与rollbackMethod一致
   *
   * @param actionContext
   * @return
   */
  boolean rollback(BusinessActionContext actionContext);
  

  }

  @LocalTCC
  public interface TccAccountService {

  /**
   * 用户账户扣款
   *
   * 定义两阶段提交，在try阶段通过@TwoPhaseBusinessAction注解定义了分支事务的 resourceId，commit和 cancel 方法
   *  name = 该tcc的bean名称,全局唯一
   *  commitMethod = commit 为二阶段确认方法
   *  rollbackMethod = rollback 为二阶段取消方法
   *
   * @param userId
   * @param money 从用户账户中扣除的金额
   * @return
   */
  @TwoPhaseBusinessAction(name = "debit", commitMethod = "commit", rollbackMethod = "rollback", useTCCFence = true)
  void tryDebit(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money") int money);
  
  /**
   * 提交事务，二阶段确认方法可以另命名，但要保证与commitMethod一致
   * context可以传递try方法的参数
   *
   * @param actionContext
   * @return
   */
  boolean commit(BusinessActionContext actionContext);
  
  /**
   * 回滚事务，二阶段取消方法可以另命名，但要保证与rollbackMethod一致
   *
   * @param actionContext
   * @return
   */
  boolean rollback(BusinessActionContext actionContext);
  

  }

  @LocalTCC
  public interface TccStorageService {

  /**
   * Try： 库存 - 扣减数量， 冻结库存 + 扣减数量
   */
  @TwoPhaseBusinessAction(name = "deduct" ,commitMethod = "commit" ,rollbackMethod = "rollback",useTCCFence = true)
  void tryDeduct(@BusinessActionContextParameter(paramName = "commodityCode") String commodityCode,
              @BusinessActionContextParameter(paramName = "count") int count);
  
  /**
   * Confirm:冻结库存-扣减数量
   */
  boolean commit(BusinessActionContext actionContext);
  
  
  /**
   *
   * CanceL:库存+扣减数量，冻结库存-扣减数量
   */
  boolean rollback(BusinessActionContext actionContext);
  

  }

8.6.5 微服务增加tcc_fence_log日志表

# tcc_fence_log 建表语句如下（MySQL 语法）
CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(
    `xid`           VARCHAR(128)  NOT NULL COMMENT 'global id',
    `branch_id`     BIGINT        NOT NULL COMMENT 'branch id',
    `action_name`   VARCHAR(64)   NOT NULL COMMENT 'action name',
    `status`        TINYINT       NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
    `gmt_create`    DATETIME(3)   NOT NULL COMMENT 'create time',
    `gmt_modified`  DATETIME(3)   NOT NULL COMMENT 'update time',
    PRIMARY KEY (`xid`, `branch_id`),
    KEY `idx_gmt_modified` (`gmt_modified`),
    KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;

8.6.6 在全局事务发起者中添加@GlobalTransactional注解

    //@Transactional
    @GlobalTransactional(name="createOrder")
    public Order saveOrder(OrderVo orderVo) {
        log.info("=============用户下单=================");
        log.info("当前 XID: {}", RootContext.getXID());

        //获取对应的唯一ID
        SnowFlake snowFlake = new SnowFlake(1, 2);
        Long orderId =snowFlake.nextId();
        Order order = tccOrderService.prepareSaveOrder(orderVo,orderId);
        //扣减余额   服务降级  throw
        Boolean debit= accountFeignService.debit(orderVo.getUserId(), orderVo.getMoney());
        //扣减库存
        storageFeignService.deduct(orderVo.getCommodityCode(), orderVo.getCount());
        return order;
  
    }

8.6.7 测试

9、Saga模式

9.1 基本机制

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务（执行处理时候出错了，给一个修复的机会）都由业务开发实现。

Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

9.2 为什么需要Saga

之前我们学习的Seata分布式三种操作模型中所使用的的微服务全部可以根据开发者的需求进行修改，但是在一些特殊环境下，比如老系统，封闭的系统（无法修改，同时没有任何分布式事务引入），那么AT、XA、TCC模型将全部不能使用，为了解决这样的问题，才引用了Saga模型。

比如：事务参与者可能是其他公司的服务或者是遗留系统，无法改造，可以使用Saga模式。

Saga模式是Seata提供的长事务解决方案，提供了异构系统的事务统一处理模型。在Saga模式中，所有的子业务都不在直接参与整体事务的处理（只负责本地事务的处理），而是全部交由了最终调用端来负责实现，而在进行总业务逻辑处理时，在某一个子业务出现问题时，则自动补偿全面已经成功的其他参与者，这样一阶段的正向服务调用和二阶段的服务补偿处理全部由总业务开发实现。

9.3 Saga状态机

目前Seata提供的Saga模式只能通过状态机引擎来实现，需要开发者手工的进行Saga业务流程绘制，并且将其转换为Json配置文件，而后在程序运行时，将依据子配置文件实现业务处理以及服务补偿处理，而要想进行Saga状态图的绘制，一般需要通过Saga状态机来实现。

基本原理：

• 通过状态图来定义服务调用的流程并生成json定义文件
• 状态图中一个节点可以调用一个服务，节点可以配置它的补偿节点
• 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚
• 可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能

9.4 Saga状态机的应用

官方提供了一个状态机设计器

官方文档地址：https://seata.io/zh-cn/docs/user/saga.html

Seata Safa状态机可视化图形设计器使用地址：https://github.com/seata/seata/blob/develop/saga/seata-saga-statemachine-designer/README.zh-CN.md