SpringCloud：分布式事务Seata事务模式

旧城等待， 2024-03-16 19:26 43阅读 0赞

`Seata`会有 4 种分布式事务解决方案，分别是`AT`模式、`TCC`模式、`Saga`模式和`XA`模式。

![在这里插入图片描述][3642de89fd5f4377b6287f4e3b74f45a.png_pic_center]

### 1.AT 模式 ###

2019 年 1 月份，`Seata`开源了`AT`模式。`AT`模式是一种无侵入的分布式事务解决方案。在`AT`模式下，用户只需关注自己的**业务`SQL`**，用户的 **业务`SQL`** 作为一阶段，`Seata`框架会自动生成事务的二阶段提交和回滚操作。

![在这里插入图片描述][4fb63c2e59a246dc96567c8dbd3d5e47.png_pic_center]

#### 1.1.前提 ####

*  基于支持本地`ACID`事务的关系型数据库。
 *  `Java`应用，通过`JDBC`访问数据库。

#### 1.2.整体机制 ####

两阶段提交协议的演变：

*  一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
 *  二阶段：
    
     *  提交异步化，非常快速地完成。
     *  回滚通过一阶段的回滚日志进行反向补偿。

在一阶段，`Seata`会拦截**业务`SQL`**，首先解析`SQL`语义，找到**业务`SQL`要更新的业务数据，在业务数据被更新前，将其保存成`before image`**，然后执行**业务`SQL`更新业务数据，在业务数据更新之后，再将其保存成`after image`**，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

![在这里插入图片描述][9df67f44f049488fa168b423d5806f28.png_pic_center]

二阶段如果是提交的话，因为**业务`SQL`** 在一阶段已经提交至数据库， 所以`Seata`框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

![在这里插入图片描述][8ec15b05866c4f04996c08c74f102103.png_pic_center]

二阶段如果是回滚的话，`Seata`就需要回滚一阶段已经执行的**业务`SQL`**，还原业务数据。回滚方式便是用\*\*`before image`**还原业务数据；但在还原前要首先要校验脏写，对比**数据库当前业务数据\*\*和 **`after image`**，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

![在这里插入图片描述][f7b0861d37a849f8bb744ef7b5363714.png_pic_center]

`AT`模式的一阶段、二阶段提交和回滚均由`Seata`框架自动生成，用户只需编写**业务`SQL`**，便能轻松接入分布式事务，`AT`模式是一种对业务无任何侵入的分布式事务解决方案。

### 2.`TCC`模式 ###

2019 年 3 月份，`Seata`开源了`TCC`模式，该模式由蚂蚁金服贡献。`TCC`模式需要用户根据自己的业务场景实现 `Try`、`Confirm`和`Cancel`三个操作；事务发起方在一阶段 执行`Try`方式，在二阶段提交执行`Confirm`方法，二阶段回滚执行`Cancel`方法。

![在这里插入图片描述][0e83df82d4a64723914b33d76ee3c922.png_pic_center]

`TCC`三个方法描述：

*  `Try`：资源的检测和预留；
 *  `Confirm`：执行的业务操作提交；要求`Try`成功`Confirm`一定要能成功；
 *  `Cancel`：预留资源释放。

**业务模型分 2 阶段设计：**

用户接入`TCC`，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。

以**扣钱**场景为例，在接入`TCC`前，对`A`账户的扣钱，只需一条更新账户余额的`SQL`便能完成；但是在接入`TCC`之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段`Try`成功的话 二阶段`Confirm`一定能成功。

![在这里插入图片描述][261d4281b42245eb9581d23da4cfc0ef.png_pic_center]

如上图所示，

`Try`方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，`Try`要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结`A`账户的 转账资金。`Try`方法执行之后，账号`A`余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。

二阶段`Confirm`方法执行真正的扣钱操作。`Confirm`会使用`Try`阶段冻结的资金，执行账号扣款。`Confirm`方法执行之后，账号`A`在一阶段中冻结的 30 元已经被扣除，账号`A`余额变成 70 元 。

如果二阶段是回滚的话，就需要在`Cancel`方法内释放一阶段`Try`冻结的 30 元，使账号`A`的回到初始状态，100 元全部可用。

用户接入`TCC`模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成`TCC`的 3 个方法，并且保证`Try`成功`Confirm` 一定能成功。相对于`AT`模式，`TCC`模式对业务代码有一定的侵入性，但是`TCC`模式无`AT`模式的全局行锁，`TCC`性能会比`AT`模式高很多。

### 3.`Saga`模式 ###

`Saga`模式是`Seata`提供的长事务解决方案，由蚂蚁金服主要贡献。在`Saga`模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

![在这里插入图片描述][62903566747740c0846cf3a4c816e084.png_pic_center]

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

#### 3.1.适用场景 ####

*  业务流程长、业务流程多
 *  参与者包含其它公司或遗留系统服务，无法提供`TCC`模式要求的三个接口

#### 3.2.优势 ####

*  一阶段提交本地事务，无锁，高性能
 *  事件驱动架构，参与者可异步执行，高吞吐
 *  补偿服务易于实现

#### 3.3.缺点 ####

*  不保证隔离性

### 4.`XA`模式 ###

`XA`模式是`Seata`将会开源的另一种无侵入的分布式事务解决方案，任何实现了`XA`协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如`MySql`、`Oracle`、`DB2`、`Oceanbase`等均支持`XA`协议。

`XA`协议有一系列的指令，分别对应一阶段和二阶段操作。 **`xa start`** 和 **`xa end`用于开启和结束`XA`事务；`xa prepare`** 用于预提交`XA`事务，对应一阶段准备；\*\*`xa commit`**和**`xa rollback`\*\*用于提交、回滚`XA`事务，对应二阶段提交和回滚。

在`XA`模式下，每一个`XA`事务都是一个事务参与者。分布式事务开启之后，首先在一阶段执行 **`xa start`** 、**业务`SQL`**、**`xa end`和 `xa prepare` 完成`XA`事务的执行和预提交；二阶段如果提交的话就执行 `xa commit`，如果是回滚则执行`xa rollback`**。这样便能保证所有`XA`事务都提交或者都回滚。

![在这里插入图片描述][257bcb319bb74f12b3b69cfaf6664226.png_pic_center]

`XA`模式下，用户只需关注自己的**业务`SQL`**，`Seata`框架会自动生成一阶段、二阶段操作；`XA`模式的实现如下：

![在这里插入图片描述][24f90b19901541088fc5ff8292960ff7.png_pic_center]

*  一阶段：

在`XA`模式的一阶段，`Seata`会拦截**业务`SQL`**，在**业务`SQL`之前开启`XA`事务（`xa start`**），然后执行**业务`SQL`**，结束`XA`事务\*\*`xa end`**，最后预提交`XA`事务（**`xa prepare`\*\*），这样便完成 \*\*业务`SQL`\*\*的准备操作。

*  二阶段提交：

执行\*\*`xa commit`**指令，提交`XA`事务，此时**业务`SQL`\*\*才算真正的提交至数据库。

*  二阶段回滚：

执行\*\*`xa rollback`**指令，回滚`XA`事务，完成**业务`SQL`\*\*回滚，释放数据库锁资源。

`XA`模式下，用户只需关注**业务`SQL`**，`Seata`会自动生成一阶段、二阶段提交和二阶段回滚操作。`XA`模式和`AT`模式一样是一种对业务无侵入性的解决方案；但与`AT`模式不同的是，`XA`模式将快照数据和行锁等通过`XA`指令委托给了数据库来完成，这样`XA`模式实现更加轻量化。

[3642de89fd5f4377b6287f4e3b74f45a.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/0ee1db3c30464f42a89e3e52bdb80dd9.png
[4fb63c2e59a246dc96567c8dbd3d5e47.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1ae6a6b10c5947269c7ef54e202fdb3b.png
[9df67f44f049488fa168b423d5806f28.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7c83dda7bfd94a79a9fb9c4ea61963b2.png
[8ec15b05866c4f04996c08c74f102103.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/634adeb1d60245688a048f39726bfd64.png
[f7b0861d37a849f8bb744ef7b5363714.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7136b6e3cef74f0599cab877c6bcf6a6.png
[0e83df82d4a64723914b33d76ee3c922.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/1b9ba8095bf94e4b9ae1c6d2a777949c.png
[261d4281b42245eb9581d23da4cfc0ef.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7ada14d6a42747d1a6018e1503e4c0b4.png
[62903566747740c0846cf3a4c816e084.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e5d30ebe43774aeebff404f474b507fc.png
[257bcb319bb74f12b3b69cfaf6664226.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/ccb59aeb94e6400eb57da7a0d4a7636e.png
[24f90b19901541088fc5ff8292960ff7.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/990f04d4392f47c28f6ff1b849440547.png