一站式分布式事务 Seata 方案-51CTO.COM

引言

上一篇《如何选择分布式事务解决方案？》综合比较了各种分布式事务方案的优缺点，并在技术选型上给出合理化的建议。考虑到企业应用的普遍性和适用性，今天重点聊聊分布式Seata方案实践和原理。

Seata 是什么?

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

英文官网：https://seata.io/zh-cn/

中文官网：https://seata.io/zh-cn/

看官网这轻松而有趣的解释，心中默念：

为探究这个问题，我们尝试从问题中来，到问题中去。试想：

不使用分布式事务会产生怎样的结果？
为何选择Seata方案？
这种方案如何实现提交和回滚保证数据一致性的？

带着这些问题，根据实际应用场景逐步探究。。。

业务场景

在电商交易系统中，最核心的业务场景：下订单 --> 减库存 --> 调支付，要求具备数据强一致性。

基本模型如下：

我们要求该场景应满足以下几个条件：

订单状态正常（0-异常，1-正常）
库存不能出现负数或者下单了没有扣库存
保证金额正常支付，不能出现扣款多或者扣款少的情况

业务实现

下面我们给出核心代码描述业务过程。

订单服务：

public interface OrderService {
    /**
    * 创建订单
    */
   void create(Order order);
}1.
2.
3.
4.
5.
6.

仓储服务：

public interface StorageService {
    /**
     * 扣减库存
     */
    void deduct(Long productId, Integer count);
}1.
2.
3.
4.
5.
6.

帐户服务：

public interface AccountService {

  /**
   * 扣减账户余额
   *
   * @param userId 用户id
   * @param money  金额
   */
  void debit(@RequestParam("userId") Long userId, @RequestParam("money") BigDecimal money);
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

这里只给出核心业务逻辑说明问题。在订单业务作为核心逻辑，远程调用扣库存和支付。

public class OrderServiceImpl implements OrderService
{
    @Resource
    private OrderDao orderDao;
    @Resource
    private StorageService storageService;
    @Resource
    private AccountService accountService;

    /**
     * 创建订单->调用库存服务扣减库存->调用账户服务扣减账户余额->修改订单状态
     * 简单说：下订单->扣库存->减余额->改状态
     */
    @Override
    //这里先注释掉，用于比较实用分布式事务前后的效果
    //@GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
    public void create(Order order)
    {
        //创建订单
        orderDao.create(order);

        //2 扣减库存
        storageService.deduct(order.getProductId(),order.getCount());

        //3 扣减账户金额
        accountService.debit(order.getUserId(),order.getMoney());

        //4 修改订单状态，从零到1,1代表已经完成
        orderDao.update(order.getUserId(),0);

    }
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

未使用分布式事务前的场景

初始状态：

-- 库存商品：100
mysql> select * from t_storage;
+----+------------+-------+------+---------+
| id | product_id | total | used | residue |
+----+------------+-------+------+---------+
|  1 |          1 |   100 |    0 |     100 |
+----+------------+-------+------+---------+
1 row in set (0.00 sec)
 
  
--账户余额：1000
mysql> select * from t_account;
+----+---------+-------+------+---------+
| id | user_id | total | used | residue |
+----+---------+-------+------+---------+
|  1 |       1 |  1000 |    0 |    1000 |
+----+---------+-------+------+---------+
1 row in set (0.00 sec)

  
-- 订单为空 
mysql> select * from t_order;
Empty set (0.00 sec)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

下面模拟一个账户扣减异常（因为OpenFeign的默认分别是连接超时时间10秒.这处设置20秒就是为了挑事儿），然后分别启动订单、库存、账户服务。

/**
   * 扣减账户余额
   */
  @Override
  public void debit(Long userId, BigDecimal money) {
      LOGGER.info("------->account-service中扣减账户余额开始");
      //模拟超时异常，全局事务回滚
      //暂停几秒钟线程
      try { TimeUnit.SECONDS.sleep(20); } catch (InterruptedException e) { e.printStackTrace(); }
      accountDao.debit(userId,money);
      LOGGER.info("------->account-service中扣减账户余额结束");
  }1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

模拟下订单过程：

http://localhost:2001/order/create?userId=1&productId=1&count=10&mnotallow=100

页面异常因为账户服务中扣减过程发生异常。我们再来观察数据库中的变化情况：

-- 库存商品：100
mysql> select * from t_storage;
+----+------------+-------+------+---------+
| id | product_id | total | used | residue |
+----+------------+-------+------+---------+
|  1 |          1 |   100 |   10 |      90 |
+----+------------+-------+------+---------+
1 row in set (0.00 sec)
 
  
--账户余额：1000
mysql> select * from t_account;
+----+---------+-------+------+---------+
| id | user_id | total | used | residue |
+----+---------+-------+------+---------+
|  1 |       1 |  1000 |    0 |    1000 |
+----+---------+-------+------+---------+
1 row in set (0.00 sec)


  
-- 订单为空 
mysql> select * from t_order;
+----+---------+------------+-------+-------+--------+
| id | user_id | product_id | count | money | status |
+----+---------+------------+-------+-------+--------+
|  3 |       1 |          1 |    10 |   100 |      0 |
+----+---------+------------+-------+-------+--------+
1 row in set (0.00 sec)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

观察分析，订单状态：0-异常。库存较少，但是余额没有扣减。商家容易哭死。这就使我们不得不做事务的控制。以达到数据一致性。

Seata方案引入

对此，我们使用分布式事务Seata的解决方案解决此问题。

图片来源于官网

为方便测试使用，这里准备了Seata的一套环境。并给出相应业务测试用例SQL。

使用非常简单。只需要在核心业务方法上加一个注解@GlobalTransactional即可。

@Override
    @GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
    public void create(Order order)
    {
        //创建订单
        orderDao.create(order);

        //2 扣减库存
        storageService.deduct(order.getProductId(),order.getCount());

        //3 扣减账户金额
        accountService.debit(order.getUserId(),order.getMoney());

        //4 修改订单状态，从零到1,1代表已经完成
        orderDao.update(order.getUserId(),0);

    }1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

恢复数据初始状态，再次启动和重复上述测试步骤。观察在发生异常的情况下，数据库还是初始的状态（为出现订单异常和账户余额变动的问题）。显然：这个注解帮助我们：在分布式环境下，当有异常发生时进行全局回滚，以维持数据的一致状态。我们把这种全局意义上控制的事务成为全局事务。

Seata执行流程及原理

@GlobalTransactional用事实告诉我们：极简是一种美！

是不是很好奇？

下面究其背后的原理做深层次的探究。

(1) 全局事务中的角色

TM 事务发起方，是业务方法上带有@GlobalTransactional注解的服务，如：本案例中订单服务。
TC 事务协调者，可以理解为一个隐形的中间人，负责管理事务。
TR 事务参与者：本案例当中：订单、库存、账户都是还是事务参与者

(2) 全局成功提交流程

(3) 全局失败回滚流程

下面我们用代码验证此过程：

启动nacos；
启动seata；
debug启动订单、库存、账户服务，断点跟踪

查看数据库变化情况（取关键字段信息）：

-- 全局事务
mysql> select xid,transaction_id,application_id,transaction_service_group,transaction_name from global_table ;
+-------------------------------+----------------+---------------------+---------------------------+------------------+
| xid                           | transaction_id | application_id      | transaction_service_group | transaction_name |
+-------------------------------+----------------+---------------------+---------------------------+------------------+
| 192.168.0.101:8091:2155601919 |     2155601919 | seata-order-service | fsp_tx_group              | fsp-create-order |
+-------------------------------+----------------+---------------------+---------------------------+------------------+
1 row in set (0.01 sec)

  
-- 分支事务
mysql> select  xid,transaction_id,branch_id,client_id,branch_type from  branch_table;
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
| xid                           | transaction_id | branch_id  | client_id                                 | branch_type |
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
| 192.168.0.101:8091:2155601919 |     2155601919 | 2155601922 | seata-order-service:192.168.0.101:51952   | AT          |
| 192.168.0.101:8091:2155601919 |     2155601919 | 2155601927 | seata-storage-service:192.168.0.101:52459 | AT          |
| 192.168.0.101:8091:2155601919 |     2155601919 | 2155601930 | seata-account-service:192.168.0.101:52498 | AT          |
+-------------------------------+----------------+------------+-------------------------------------------+-------------+
3 rows in set (0.00 sec)

  
-- 锁
mysql> select xid,transaction_id,branch_id,table_name,resource_id  from lock_table;
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
| xid                           | transaction_id | branch_id  | table_name | resource_id                                   |
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
| 192.168.0.101:8091:2155601919 | 2155601919     | 2155601930 | t_account  | jdbc:mysql://114.116.10.56:3306/seata_account |
| 192.168.0.101:8091:2155601919 | 2155601919     | 2155601922 | t_order    | jdbc:mysql://114.116.10.56:3306/seata_order   |
| 192.168.0.101:8091:2155601919 | 2155601919     | 2155601927 | t_storage  | jdbc:mysql://114.116.10.56:3306/seata_storage |
+-------------------------------+----------------+------------+------------+-----------------------------------------------+
3 rows in set (0.00 sec)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.