SpringCloud Alibaba - Seata 四种分布式事务解决方案（XA、AT）+ 实践部署（上）

太过爱你忘了你带给我的痛 2024-02-26 05:10 5阅读 0赞

**目录**

一、Seata 分布式事务解决方案

1.1、XA 模式

1.1.1、XA模式理论

第一阶段：

第二阶段：

1.1.2、Seata 框架中的 XA 模式

第一阶段：

第二阶段：

1.1.3、XA 模式的优缺点

1.2.4、实现Seata 的 XA 模式

a）修改 application 文件（每一个参与事务的微服务）

b）给发起全局事务中的入口方法添加 @GlobalTransactional 注解

c）重启服务并测试

1.2、AT 模式

1.2.1、AT 模式理论

第一阶段：

第二阶段：

问题：XA模式 和 AT模式 的区别？

1.2.2、AT 模式脏写问题

1.2.3、解决办法：写隔离

1.2.4、AT 模式的优缺点

1.2.5、实现 AT 模式

a）建表

b）修改 application.yml 文件

c）重启服务并测试

--------------------

## 一、Seata 分布式事务解决方案 ##

--------------------

### 1.1、XA 模式 ###

#### 1.1.1、XA模式理论 ####

XA 模式是 X/Open 组织定义的一个分布式事务处理的标准，可以认为是分布式事务领域最早的标准了，所以几乎所有主流的数据库（mysql、oracle......）都是实现了这种标准. 换言之，这些数据库内部已经能够基于 XA 模式实现分布式事务了.

> 这种模式把分布式定义成了以下两个阶段

##### 第一阶段： #####

这一阶段也叫做准备阶段，事务协调者 会向 资源管理器 发起一个准备的请求，也就是告诉他：“你可以去执行业务 sql 了啊，但是执行完了以后不可以提交！”. 随后，资源管理器 就执行数据库业务，然后将执行结果告诉 事务协调者（执行成功了，就是就绪状态；失败了，就是 fail 状态），这样 事务协调者 就可以根据结果判断下一个阶段要干什么.

![1f3bf73ed7b84ace89f0541f78aca7c6.png][]

##### 第二阶段： #####

事务协调者收到 RM 的反馈之后，就会进行判断. 如果都执行成功了，就通知这些 RM：“你们可以提交了啊”，然后 RM 收到请求，就把事务提交了，整个事务也就结束了；如果有任意一个服务执行失败了，那么事务协调者就会通知这些RM，让他们全部回滚.

![57a0b13c30a948a6b3020dce5f2a954f.png][]

可以看出 XA 模式是一种强一致性的事务，软可用性，因为事务没有提交的时候，拿不到数据库锁，是不能进行其他操作的.

#### 1.1.2、Seata 框架中的 XA 模式 ####

Seata 的 XA 模式和上述讲的 XA 模式大体相似，只是多了一个 TM 的概念. 如下图

![9f0833bb24064e1583c91fa96bc29e04.png][]

##### 第一阶段： #####

Seata 实际上就是多了一个 TM 的概念， 也就是事务管理者. TM 一上来就是要去注册全局事务，作为分布式事务的入口，接下来就会去调用各个分支事务. 每个分支事务中又有一个 RM，RM 就回去 TC 里面注册分支事务，然后执行业务 sql，但是执行完后不能提交，只是去报告一下事务的状态. 到此，第一阶段结束.

##### 第二阶段： #####

TM 这里的入口方法执行完了以后，就要去告诉 TC 说：“我这边执行完了，接下来就看你那边的情况了~”. 随后 TC 就会去检查各个分支事务报告的状态，然后向 RM 发送一个信号——如果第一阶段都执行成功了，那么就提交，反之，则进行回滚. RM 收到信号之后就可以进行 提交/回滚 事务了.

#### 1.1.3、XA 模式的优缺点 ####

> 优点：

**1. 支持强一致：**执行完业务 sql 以后，不进行提交事务，而是等到 TC 协调完后，在进行 提交/回**滚.**

**2. 实现起来简单：**因为数据库本身就支持 XA 模式，Seata 只是在数据库的 XA 模式上做了一层简单的封装. 如果只看核心部分，就没什么差别了.

> 缺点：

**1. 弱可用性，性能差：**第一阶段不提交，等待第二阶段才提交，这个过程中会占用数据库锁（相当于对系统资源的一种浪费）. 一旦分支事务特别多的情况下，业务耗时就会很久.

**2. 依赖数据库底层实现：**虽然用起来简单了，但是如果我用的不是 mysql 这种关系型数据库，而是 redis 这种非关系型数据库就不行了.

#### 1.2.4、实现Seata 的 XA 模式 ####

##### a）修改 application 文件（每一个参与事务的微服务） #####

开启 seata 的 XA 模式

seata:
      data-source-proxy-mode: XA # 开启数据源代理的XA模式

##### b）给发起全局事务中的入口方法添加 @GlobalTransactional 注解 #####

当前案例的全局事务入口是 订单服务中的 创建订单的 create 方法（案例架构如下图）.

![ff5cbe86dbff4149844c8267a775a355.png][]

这里只需要在 create 方法上添加 @GlobalTransactional 注解即可

@Override
        @GlobalTransactional
        public Long create(Order order) {
            // 创建订单
            orderMapper.insert(order);
            try {
                // 扣用户余额
                accountClient.deduct(order.getUserId(), order.getMoney());
                // 扣库存
                storageClient.deduct(order.getCommodityCode(), order.getCount());
            } catch (FeignException e) {
                log.error("下单失败，原因:{}", e.contentUTF8(), e);
                throw new RuntimeException(e.contentUTF8(), e);
            }
            return order.getId();
        }

##### c）重启服务并测试 #####

> Ps：这里不要忘了先启动 Nacos 和 TC 服务.

以下分别为用户余额和库存数量.

![aa1bb699a0b74d1a8bdef2d89b51584c.png][]

![115d7f4063e541f6b0f9adf48206ca59.png][]

1. 这里使用 Postman 发送以下请求（减少 9 个库存数量，用户余额减少 200）

http://localhost:8082/order?userId=user202103032042012&commodityCode=100202003032041&count=9&money=200

![9d3109af24cb4dae90d9d31ce6e6a54e.png][]

2. 随后可以看到订单微服务返回 500 错误.

![b229eba1b0dc49cba26093d889b198a9.png][]

在扣款微服务中，先进行了扣款业务，但是随后 rm 又执行了回滚

![5b91fb0286384f39a2a51fcb6fa05944.png][]

在库存微服务中，可以看到扣减失败.

![a9d54dc49de74c1aba05e596f8546c69.png][]

最后观察数据库中数据，可以看到事务已经回滚如初.

![aa1bb699a0b74d1a8bdef2d89b51584c.png][]

![115d7f4063e541f6b0f9adf48206ca59.png][]

### 1.2、AT 模式 ###

#### 1.2.1、AT 模式理论 ####

AT 模模式也是分阶段性提交的事务模型. 他的出现正式为了解决 XA 模式中资源锁定周期过长的一个缺陷.

> AT 模式也分为两个阶段

![3bb98b267a7946e1960c38abac798136.png][]

##### 第一阶段： #####

TM 去开启全局事务，作为分布式事务的入口，接着又会调用每一个分支事务 ，然后每个分支事务里的 rm 都会去注册分支事务，并执行本地的业务 sql，然后直接提交（这里就和 XA 不一样了）. 因此 AT 模式就不需要像 XA 那样锁定资源，性能上要优于 XA 模式.

这里直接提交，万一有人失败了呢，没办法回滚不就导致状态不一致了吗？

实际上 AT 模式在执行 sql 之前，rm 会给当前数据生成一个快照，这个快照的名字叫 “undo log”，这就像是 redis 中 RDB 持久化时也会生成快照，那么即使服务重启，也可以根据快照恢复数据. 那么这样就即使有分支事务执行 sql 的时候失败了，也可以根据快照恢复如初，大胆提交就对了.

##### 第二阶段： #####

TM 看到业务结束了，就会去通知 TC，那么 TC 就会判断是提交还是回滚. 如果分支事务的状态都是成功的，那就可以把第一阶段准备的快照给删了（删快照这个动作是异步的，因为第一阶段都成功了，也提交了，后面的事情就可以用一个线程独立去做，提高了效率）. 如果第一阶段有人失败了，就要基于 undo log 恢复数据，恢复以后这个 log 也就没用了，最后也会删除.

##### 问题：XA模式 和 AT模式 的区别？ #####

1. XA模式在第一阶段的时候不会进行事务的提交，而 AT 模式执行完业务 sql 之后会立即提交事务，不会锁定资源，因此性能会好一些.

2. XA 依赖于数据库的机制来做回滚，而 AT 模式因为已经提交了，就不能回滚，他是通过给自己生成快照的方式来实现数据的恢复.

3. XA 模式是强一致，而 AT 是最终一致，因为 AT 在业务 sql 执行之后直接提交了，有人失败，有人成功，那么这个时候状态肯定是不一致的，也就是一个软状态，只有在第二阶段，基于快照恢复了数据，才能到达一个最终一致的效果.

#### 1.2.2、AT 模式脏写问题 ####

*AT 模式在第一阶段执行完业务 sql 以后会直接提交，那么资源锁定的周期就比较短，效率高，但也正因为他提前释放了锁，就导致在高并发的场景下，会出现安全问题~*

例如我这里有一个用户余额表，里面记录了 money 字段，表示余额.

1.  现在有一个线程开启了事务1，首先他会去获取数据库锁，接着生成快照（money = 100），然后执行业务 sql（把 money 值改成 90），最后提交事务，锁也就释放了.
2.  此时，另一个线程开启了 事务2 ，拿到锁以后保存快照（money = 90），执行业务 sql（把 money 值改成 80），最后提交释放锁.

到了第二阶段，假如说 事务1 要进行回滚（通过快照恢复数据），但是 事务1 的快照数据 money = 100！这个时候就出问题了，恢复了以后相当于 事务2 这哥们啥也没做. 这就是所谓的脏写问题.

![5ed246df766e41059b4968882f2f1b1e.png][]

#### 1.2.3、解决办法：写隔离 ####

上述过程出现的问题，归根结底还是**隔离性的原因**，如果第一阶段和第二阶段整体都是一个锁定状态，别人根本无法插入进来，因此 AT 模式就引入了一个东西叫 “全局锁”.

> Ps：全局锁由 TC 来控制，用来记录当前哪个事务在操作哪种表的哪一行数据. 这张表了主要有 事务id、表名字、pk主键（记录这张表的哪一行数据）.

1.  有了全局锁，那么在刚刚上述栗子的 事务1中，执行完业务 sql 就会去获取全局锁，就表明这张表的这行数据是我 事务1 才能拥有的，此时就可以大胆的提交事务.
2.  当 事务2 执行完业务 sql 之后，也尝试去获取全局锁，但是由于 事务1 已经获取了，因此 事务2 就只能阻塞等待 事务1 释放锁. 事务1 想要释放全局锁得等到第二阶段结束，但是现在 事务2 又持有 DB 锁，事务1 也拿不到 DB 锁，因此事务就互相等待，直到 事务2 等待超时，就会进行回滚并释放 DB 锁.

这样也就实现了 事务1 在执行第一阶段和第二阶段的时候，任何人都不能来执行，起到了很好的 隔离效果.

![227cb56a86e042b0a20a627240c4de2b.png][]

> 问题一：有人可能就会说，那这不跟 XA 模式一样了？也锁定资源，这样别人也无法访问，效率不久下降了么？

这里实际上是有一个 锁粒度 上的差别. XA 模式中是数据库锁不释放，意味着任何人都不能访问你这数据库的数据，而 AT 中的全局锁只是不能任何人操作这个表中的某一行数据，也就是说，同样是 account 表，你可以修改这张表其他所有不是余额的字段. 因此效率上还是高很多的.

> 问题二：有人可能就会说，隔离不彻底啊，可能有一种极端情况，就是在修改 money 的过程中，有一个其他 非Seata 管理的事务 也来修改 money 字段，这时候人家又不用获取全局锁，也可能出现脏写的问题

确实有可能，但是可能性非常低，有以下两个原因：

1.  全局事务大多数情况下都是成功的，比如我这边转账，大多数情况下我不能明知道钱不够还去转超额的钱吧，那么第二阶段几乎就不会回滚.
2.  分布式事务耗时本来就长，或者说并发本来就比较低，像这种见缝插针的事务就更少见了.

但即使概论低，Seata 也还是考虑这种情况的. Seata 在管理的事务的时候，**是保存了两个快照的，第一个是更新前的快照（money = 100），另一个是更新后的快照（money = 90）**. 在 Seata 管理的 事务1 执行到第二阶段的时候，他就会去对比数据库中的字段值 和 after-image（更新后的快照）是否一致，如果不一致，就知道其中有人动了手脚，此时他可能就会发一个短信、邮件、电话告诉你，需要人工介入了.

![dbb770bdaa9c4b14a398ae5d1d04769f.png][]

#### 1.2.4、AT 模式的优缺点 ####

> 优点：

高性能：第一阶段完成后直接提交，释放资源比较早，数据库的锁定时间短.

写隔离：利用全局锁机制，不仅实现了隔离，性能也依旧维持.

使用简单，无代码侵入：Seata 框架自动完成回滚和提交.

> 缺点：

软状态：由于第一阶段执行业务 sql 可能有人成功有人失败，并且已经提交，这种情况下，并没有达成一致，只有第二阶段快照恢复才最终一致.

影响性能：虽然相比 XA模式，性能要好很多，但是框架的快照功能多多少少都会影响一点性能.

#### 1.2.5、实现 AT 模式 ####

##### a）建表 #####

AT 模式下会引入全局锁，因此需要 lock\_table 表来记录（在 TC 服务关联的数据库中创建）.

DROP TABLE IF EXISTS `lock_table`;
    CREATE TABLE `lock_table`  (
      `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
      `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
      `transaction_id` bigint(20) NULL DEFAULT NULL,
      `branch_id` bigint(20) NOT NULL,
      `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
      `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
      `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
      `gmt_create` datetime NULL DEFAULT NULL,
      `gmt_modified` datetime NULL DEFAULT NULL,
      PRIMARY KEY (`row_key`) USING BTREE,
      INDEX `idx_branch_id`(`branch_id`) USING BTREE
    ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

AT 模式还需要保存快照，因此需要 undo\_log 表来记录（在 微服务 关联的数据库中导入）.

DROP TABLE IF EXISTS `undo_log`;
    CREATE TABLE `undo_log`  (
      `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
      `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
      `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',
      `rollback_info` longblob NOT NULL COMMENT 'rollback info',
      `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',
      `log_created` datetime(6) NOT NULL COMMENT 'create datetime',
      `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',
      UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
    ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;

##### b）修改 application.yml 文件 #####

将事务模式修改为 AT 模式即可.

seata:
      data-source-proxy-mode: AT # 开启数据源代理的AT模式

##### c）重启服务并测试 #####

以下分别为用户余额和库存数量.

![aa1bb699a0b74d1a8bdef2d89b51584c.png][]

![115d7f4063e541f6b0f9adf48206ca59.png][]

1. 这里使用 Postman 发送以下请求（减少 9 个库存数量，用户余额减少 200）

![9d3109af24cb4dae90d9d31ce6e6a54e.png][]

2. 随后可以看到订单微服务返回 500 错误.

![f52a98ddccae40ff859dd89c75780a5d.png][]

3. 扣款服务中进行扣款业务，最后回滚

![b44e689df7b747b59a8cfdab283b17d2.png][]

4. 检查数据库数据回滚成功~

![aa1bb699a0b74d1a8bdef2d89b51584c.png][]

![115d7f4063e541f6b0f9adf48206ca59.png][]

![2064009496dd4860baabf85cd246c9d0.gif][]

[1f3bf73ed7b84ace89f0541f78aca7c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/3ff2364f8d86443cabb4c6216ade998c.png
[57a0b13c30a948a6b3020dce5f2a954f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/b856a618504c47829ae37e1d9c049559.png
[9f0833bb24064e1583c91fa96bc29e04.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/cb489b17f7ad40eabdc96b7e7d838c47.png
[ff5cbe86dbff4149844c8267a775a355.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/01450734ab2d45e18c9902c8fed307a8.png
[aa1bb699a0b74d1a8bdef2d89b51584c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/0f5993befbe34a5dbfa744e480779efc.png
[115d7f4063e541f6b0f9adf48206ca59.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/83dfd9c1921646d89c385cd011c588e0.png
[9d3109af24cb4dae90d9d31ce6e6a54e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/ab5d0bffce4341e59462a66e15dbd4a9.png
[b229eba1b0dc49cba26093d889b198a9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/167b21541c24446799048fe4277aad22.png
[5b91fb0286384f39a2a51fcb6fa05944.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/312c248dbf624cba9c64cca7977a9721.png
[a9d54dc49de74c1aba05e596f8546c69.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/582e21b8eff14add8ff48d031ba3f206.png
[3bb98b267a7946e1960c38abac798136.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/1970fd901f3b4beb9d661f2b39e5fad8.png
[5ed246df766e41059b4968882f2f1b1e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/1fc42f7921434cdd8b2a9be51444f37a.png
[227cb56a86e042b0a20a627240c4de2b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/e801b46d163e4d69aa274b0e5341d551.png
[dbb770bdaa9c4b14a398ae5d1d04769f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/32205912408f422faea6c759486dd591.png
[f52a98ddccae40ff859dd89c75780a5d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/65a3d6fb886e43069d32f61a6e0499d6.png
[b44e689df7b747b59a8cfdab283b17d2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/715b252cc6dd4398a8f386921f6dd502.png
[2064009496dd4860baabf85cd246c9d0.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/26/a24b775071cc47dc94e305ab2d859d6a.png