分布式事务之Seata开源方案

前面的文章中介绍了分布式事务的概念以及一些解决方案。Seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata将为用户提供了AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案。

Seata介绍

下面以一个用户下单购买商品的系统为例，介绍开源框架Seata的原理和使用，下单该系统涉及三部分服务：

1. 仓储服务：对给定的商品扣除仓储数量；
2. 订单服务：根据采购需求创建订单；
3. 帐户服务：从用户帐户中扣除余额；

分布式事务的主要作用是保证微服务情况下用户下单过程中数据的一致性。这里的一致性可以这样理解：不会出现用户余额扣除成功，但是仓储和订单相关操作失败的场景，三者要么同时成功，要么同时失败。

单机事务场景

如果用户下单购买商品涉及到的服务都在一个传统的单机服务中，三部分服务可以共享同一个数据库实例。这种情况下，我们可以通过本地事务的一致性保证仓储/订单/账户三者之间数据的一致性。

如上图所示，在单机服务中，三部分内容共用同一个数据库实例，所以我们只需要本地事务就可以解决数据的一致性，以Spring框架为例，我们只需要在方法上添加@Transaction注解就可以实现整个购买流程中数据的一致性：

@Transaction
public void purchase(){
    doStoreBusiness();
    doOrderBusiness();
    doAccountBusiness();
}

分布式事务场景

在微服务框架中，仓储/订单/账户服务部署在不同的服务器上，使用不同的数据库实例，与单机模式完全不同。单机模式中的事务通常要求事务涉及的数据源为同一个，并且事务涉及的数据库操作在同一个数据库链接中，分布式情况下显然不满足条件。

所以在分布式场景如何保证数据的一致性呢？这就是Seata需要解决的问题了。

Seata解决方案

Seata是用于解决分布式事务的开源框架，其内部有关于分布式事务的定义如下：分布式事务是由多个分支事务组成的全局事务，其中每个分支事务都是本地事务的形式。

Seata框架包含三部分内容：

1. 事务协调器（Transaction Coordinator，TC）：维护全局事务和分支事务的状态，进行全局事务提交或全局事务回滚；
2. 事务管理器（Transaction Manager，TM）：定义全局事务，开启全局事务、提交全局事务或回滚全局事务；
3. 资源管理器（Resource Manager，RM）：管理分支事务中的资源，向事务管理器注册分支事务和并报告分支事务的状态，负责分支事务提交或回滚；

一个典型的seata分布式事务的流程如下：

1. TM向TC发出开启全局事务请求，TC生成全局事务的唯一标识XID，设此处的全局事务为T1；
2. 在全局事务T1的各个流程中，XID会作为事务的标识在微服务之间流转；
3. RM向TC注册本地事务，注册的本地事务的会作为全局事务T1的分支事务；
4. TM可以请求TC控制全局事务T1提交或全局事务T1回滚；
5. TC可以请求全局事务T1下的所有分支事务提交或回滚；

Seata历史

阿里巴巴：

• TXC：淘宝交易系统的分布式事务框架，阿里巴巴中间件团队自2014年开始启动该项目，用于解决应用架构从单一服务向微服务转变所带来的分布式事务问题；
• GTS：全球交易服务。TXC作为阿里云中间件产品，新名称GTS于2016年发布；
• Fescar：2019年开始了基于TXC/GTS的开源项目Fescar，用于开源项目社区发展；

蚂蚁金服：

• XTS：扩展事务服务。蚂蚁金服中间件团队自2007年开始开发分布式事务中间件，该中间件在蚂蚁金服中得到广泛应用，解决了跨数据库和服务的数据一致性问题。
• DTX：分布式事务扩展。自2013年以来，XTS已在蚂蚁金融云上发布，名称为DTX；

Seata社区：

• Seata：简单的可扩展分布式事务解决方案，蚂蚁金服将Fedscar改名为Seata并开源，使其成为一个中立、开放的分布式事务社区。

Seata Maven依赖

<seata.version>1.4.2</seata.version>

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-all</artifactId>
    <version>${seata.version}</version>
</dependency>

Seata案例

以上文中的用户下单购买商品的系统为例，展示Seata的使用方式：

1. 仓储微服务：对给定的商品扣除仓储数量；
2. 订单微服务：根据采购需求创建订单；
3. 帐户微服务：从用户帐户中扣除余额；

服务接口的定义

对于三个微服务，我们用三个接口来抽象其内部的逻辑：

• 仓储服务

  public interface StorageService {
  
        /**
        * 扣除存储数量
        */
        void deduct(String commodityCode, int count);
    }
  

• 订单服务

    public interface OrderService {
        /**
        * 创建订单
        */
        Order create(String userId, String commodityCode, int orderCount);
    }
  

• 帐户服务

  public interface AccountService {
  
      /**
      * 从用户账户中借出
      */
      void debit(String userId, int money);
  }
  

主要业务逻辑

对于用户下单购买商品的逻辑，我们用以下代码来实现：

• 主要业务逻辑

    public class BusinessServiceImpl implements BusinessService {
  
        private StorageService storageService;
  
        private OrderService orderService;
  
        /**
        * 采购
        */
        public void purchase(String userId, String commodityCode, int orderCount) {
  
            storageService.deduct(commodityCode, orderCount);
  
            orderService.create(userId, commodityCode, orderCount);
        }
    }
  

• 订单服务业务逻辑

    public class OrderServiceImpl implements OrderService {
  
        private OrderDAO orderDAO;
  
        private AccountService accountService;
  
        public Order create(String userId, String commodityCode, int orderCount) {
  
            int orderMoney = calculate(commodityCode, orderCount);
  
            accountService.debit(userId, orderMoney);
  
            Order order = new Order();
            order.userId = userId;
            order.commodityCode = commodityCode;
            order.count = orderCount;
            order.money = orderMoney;
  
            // INSERT INTO orders ...
            return orderDAO.insert(order);
        }
    }
  

引入Seata

在服务中引入Seata服务之后，我们只需要在分布式事务最外层的方法上添加分布式事务注解@GlobalTransactional：

@GlobalTransactional
public void purchase(String userId, String commodityCode, int orderCount) {
    // ......
}

添加注解之后，在执行业务逻辑之前，Seata会先生成全局事务ID，并且在调用其它服务时，会在请求中携带全局事务ID。如果其它微服务也添加了Seata依赖，这些微服务会获取全局事务ID，并且参与到全局事务中。