分布式事务--Seata
Posted MrDevil
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式事务--Seata相关的知识，希望对你有一定的参考价值。
分布式事务--Seata
Seata是分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。
一、事务的ACID原则
在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。
| 原子性 | 事务中的所有操作，要么全部成功，要么全部失败 |
|---|---|
| 一致性 | 要保证数据库内部完整性约束、声明性约束 |
| 隔离性 | 对同一资源操作的事务不能同时发生 |
| 持久性 | 对数据库做的一切修改将永久保存，不管是否出现故障 |
二、CAP定理
分布式系统节点通过网络连接，一定会出现分区问题（P）；当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足。
分布式系统有三个指标：
- Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
- Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
- Partition tolerance （分区容错性）
- Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
- Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。
三、BASE理论
1.BASE理论是对CAP的一种解决思路，包含三个思想：
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
2.分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：
- AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
- CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
四、分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。
1.解决分布式事务的模型
- 分支事务：子系统事务；分布式事务中包含的每个子系统的事务。
- 全局事务：有关联的各个分支事务的集合；整个分布式事务。
2.解决分布式事务的思想
- 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据。
- 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚。
五、Seata架构
1.Seata事务管理中有三个重要的角色：
- TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
- TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
2.Seata提供了四种不同的分布式事务解决方案：
- XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入。
- TCC模式：最终一致的分阶段事务模式，有业务侵入。
- AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式。
- SAGA模式：长事务模式，有业务侵入。
3.nacos服务名称组成包括？
namespace（命名空间） + group（分组名称） + serviceName（服务名称） + cluster（区域）。
4.seata客户端获取tc的cluster名称方式？
以tx-group-service的值为key到vgroupMapping中查找。
六、XA模式原理
XA 规范是 X/Open 组织定义的分布式事务处理（DTP）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。
6.1 seata的XA模式
RM一阶段的工作：
- 注册分支事务到TC
- 执行分支业务sql但不提交
- 报告执行状态到TC
TC二阶段的工作：
- TC检测各分支事务执行状态
- 如果都成功，通知所有RM提交事务
- 如果有失败，通知所有RM回滚事务
RM二阶段的工作：
- 接收TC指令，提交或回滚事务
6.2 seata的XA的优缺点
XA模式的优点：
- 事务的强一致性，满足ACID原则
- 常用数据库都支持，实现简单，并且没有代码侵入
XA模式的缺点：
- 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
- 依赖关系型数据库实现事务
6.3 实现XA模式
Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：
- 修改application.yml文件（每个参与事务的微服务），开启XA模式。
- 给发起全局事务的入口方法添加@GlobalTransactional注解。
- 重启服务并测试。
七、AT模式原理
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
阶段一RM的工作：
- 注册分支事务
- 记录undo-log（数据快照）
- 执行业务sql并提交
- 报告事务状态
阶段二提交时RM的工作：
- 删除undo-log
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前
AT模式与XA模式最大的区别：
- XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
- XA模式强一致；AT模式最终一致
7.1 AT模式的脏写问题
在并发的情况下，事务一执行RM第一阶段
- 1.1.获取DB锁，保存快照
- 1.2.执行业务
- 1.3.提交事务，释放DB锁
这时DB锁释放，事务二得到DB锁，执行RM第一阶段
- 1.1.获取DB锁，保存快照
- 1.2.执行业务
- 1.3.提交事务，释放DB锁
后面被事务一获取DB锁，根据快照恢复数据，这时将快照恢复，导致事务二的操作白干了，造成数据安全性问题，隔离性没有得到保障。
7.2 AT模式的写隔离
全局锁：由TC记录当前正在操作某行数据的事务，该事务持有全局锁，具备执行权。
在并发的情况下，事务一执行RM第一阶段
- 1.1.获取DB锁（数据库锁），保存快照
- 1.2.执行业务
- 此时获取全局锁
- 1.3.提交事务，释放DB锁
这时DB锁释放，事务二得到DB锁，执行RM第一阶段
- 1.1.获取DB锁，保存快照
- 1.2.执行业务
- 此时获取全局锁，但由于事务一已经获取重试,默认30次，
间隔10毫秒 - 1.4.任务超时，回滚并释放DB锁
而这时事务一
- 等待DB锁
- 2.1.获取DB锁，根据快照恢复数据
- 释放全局锁
由于DB锁的等待时间比全局锁久，所以事务一可以等待事务二任务超时，回滚并释放DB锁，但还是有局限，全局锁只能共同作用于seata的事务，不是seata的管理全局事务也可以修改seata的字段。
解决办法
-
1.1.事务一获取DB锁，保存快照 --> before-imag
-
1.2.事务一执行业务s --> after-image（执行完后再生成一个快照）
-
在这种极端的情况下，非seata的管理全局事务修改seata的字段，提交事务，释放DB锁
-
这时事务一在2.1.获取DB锁，根据快照恢复数据，对比一下此时数据库的字段数据是否被修改过，与 after-image 进行比较即可，再释放全局锁。
-
2.2.记录异常，发送警告，人工介入
7.3 AT模式的优缺点
AT模式的优点：
- 一阶段完成直接提交事务，释放数据库资源，性能比较好
- 利用全局锁实现读写隔离
- 没有代码侵入，框架自动完成回滚和提交
AT模式的缺点：
- 两阶段之间属于软状态，属于最终一致
- 框架的快照功能会影响性能，但比XA模式要好很多
八、TCC模式原理
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
- Try：资源的检测和预留
- Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功
- Cancel：预留资源释放，可以理解为try的反向操作
8.1 TCC模式举例
一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
- 阶段一（ Try ）：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
- 阶段二：假如要提交（Confirm），则冻结金额扣减30
- 阶段二：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30
8.2 TCC模式优缺点
TCC的优点：
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点：
- 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
8.3 TCC的空回滚和业务悬挂
-
空回滚：当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚。
-
业务悬挂：对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel。
-
应当阻止执行空回滚后的try操作，避免悬挂，执行try操作需要先判断是否发生过回滚，发生过则结束；执行cancel操作也要先判断try操作是否已经执行过。
ps: TCC模式和AT模式类似，yml文件中不需要修改数据源代理的AT模式，只需要编写实现三个方法即可实现TCC模式。
九、Saga模式
Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
9.1 Saga模式优缺点
Saga模式优点
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
Saga模式缺点
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
十、四种模式对比
| XA | AT | TCC | SAGA | |
|---|---|---|---|---|
| 一致性 | 强一致 | 弱一致 | 弱一致 | 最终一致 |
| 隔离性 | 完全隔离 | 基于全局锁隔离 | 基于资源预留隔离 | 无隔离 |
| 代码侵入 | 无 | 无 | 有，要编写三个接口 | 有，要编写状态机和补偿业务 |
| 性能 | 差 | 好 | 非常好 | 非常好 |
| 场景 | 对一致性、隔离性有高要求的业务 | 基于关系型数据库的大多数分布式事务场景都可以 | 对性能要求较高的事务。有非关系型数据库要参与的事务。 | 业务流程长、业务流程多参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口 |
->微服务技术栈高级篇--分布式事务--Seata课程视频
高级篇Day2-01-分布式事务理论基础_哔哩哔哩_bilibili
<-
记录每一个学习瞬间
Seata基础使用-分布式事务
- 一、事务
- 二、分布式事务
- 三、Seata基础
1、认识Seata
2、部署TC（Server端）
3、微服务集成Seata - 四、Seata事务管理-XA模式
1、XA模式
2、XA模式特点
3、实现XA模式 - 五、Seata事务管理-AT模式
1、AT模式
2、AT模式预防脏写
3、AT模式特点
4、AT模式实现 - 六、Seata事务管理-TCC模式
1、TCC模式
2、TCC模式特点
3、TCC模式注意点
4、TCC模式实现 - 七、Seata事务管理-Saga模式
1、Saga模式
2、Saga模式特点
3、Saga模式实现 - 八、Seata事务管理对比
一、事务
1、事务介绍
事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作的请求，即这些操作要么同时成功，要么同时失败。
2、事务特性
- 原子性（Atomicity）：事务是不可分割的最小操作单元，要么全部成功，要么全部失败；
- 一致性（Consistency）：事务完成时，必须使所有的数据都保持一致状态；
- 隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行；
- 持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。
二、分布式事务
1、分布式服务案例
- ① 微服务下单业务
Ⅰ 下单业务调用订单服务：
创建订单、写入数据库；
Ⅱ 订单服务调用账户服务和库存服务：
账户服务负责扣减用户余额；
库存服务负责扣减商品库存。
- ② 存在的问题
各个子事务的一致性问题：
各个事务是非关联的，独立部署在各个机器（或者同一机器不同JVM环境中），一个事务回滚，不影响其他事务正常提交。
2、CAP定理
- Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致；
- Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝；
- Partition tolerance（分区容错）：
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区；
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务。
3、BASE理论
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
4、分布式事务处理
- ① 分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。
子系统事务称为分支事务，有关联的各个分支事务在一起称为全局事务。
- ② 基于理论处理分布式事务
Ⅰ AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致； Ⅱ CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
三、Seata基础
1、认识Seata
官方网址：Seata。
- ① Seata事务管理
Ⅰ TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚；
Ⅱ TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务；
Ⅲ RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
- ② Seata分布式事务解决方案
Ⅰ XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入；
Ⅱ TCC模式：最终一致的分阶段事务模式，有业务侵入；
Ⅲ AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式；
Ⅳ SAGA模式：长事务模式，有业务侵入。
2、部署TC（Server端）
- ① 下载
官方下载：下载中心 (seata.io)。
- ② 解压
- ③ 修改配置
此处我们将Seata服务注册到Nacos注册中心，如下配置：
registry
# tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
type = "nacos"
nacos
# seata tc 服务注册到 nacos的服务名称，可以自定义
application = "seata-tc-server"
serverAddr = "127.0.0.1:8848"
group = "DEFAULT_GROUP"
namespace = ""
cluster = "HZ"
username = "nacos"
password = "nacos"
config
# 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
type = "nacos"
# 配置nacos地址等信息
nacos
serverAddr = "127.0.0.1:8848"
namespace = ""
group = "SEATA_GROUP"
username = "nacos"
password = "nacos"
dataId = "seataServer.properties"
- ④ 添加seataServer.properties配置文件
记得按需修改数据库相关配置：
Ⅰ 驱动：com.mysql.cj.jdbc.Driver；
Ⅱ 时区：&serverTimezone=UTC；
Ⅲ 账户&密码。
# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=123
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能，提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898
- ⑤ 创建数据库表
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table` (
`branch_id` bigint(20) NOT NULL,
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`status` tinyint(4) NULL DEFAULT NULL,
`client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime(6) NULL DEFAULT NULL,
`gmt_modified` datetime(6) NULL DEFAULT NULL,
PRIMARY KEY (`branch_id`) USING BTREE,
INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table` (
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` bigint(20) NULL DEFAULT NULL,
`status` tinyint(4) NOT NULL,
`application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`timeout` int(11) NULL DEFAULT NULL,
`begin_time` bigint(20) NULL DEFAULT NULL,
`application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` datetime NULL DEFAULT NULL,
`gmt_modified` datetime NULL DEFAULT NULL,
PRIMARY KEY (`xid`) USING BTREE,
INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
SET FOREIGN_KEY_CHECKS = 1;
- ⑥ 启动TC服务
Win指令：start seata-server.bat。
3、微服务集成Seata
- ① 引入依赖
按需改成自己下载版本依赖即可，此处以1.4.2版本为例：
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<exclusions>
<!--版本较低，1.3.0，因此排除-->
<exclusion>
<artifactId>seata-spring-boot-starter</artifactId>
<groupId>io.seata</groupId>
</exclusion>
</exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<version>$seata.version</version>
</dependency>
*② 修改配置文件application.yml
seata:
registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
# 参考tc服务自己的registry.conf中的配置
type: nacos
nacos: # tc
server-addr: 127.0.0.1:8848
namespace: ""
group: DEFAULT_GROUP
application: seata-tc-server # tc服务在nacos中的服务名称
cluster: HZ
username: nacos
password: nacos
tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
service:
vgroup-mapping: # 事务组与TC服务cluster的映射关系
seata-demo: HZ
让微服务通过注册中心找到seata-tc-server（namespace + group + serviceName + cluster），需要配置事务组的信息，如下：
四、Seata事务管理-XA模式
1、XA模式
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。
- ① 一阶段
RM一阶段的工作：
Ⅰ 注册分支事务到TC；
Ⅱ 执行分支业务sql但不提交；
Ⅲ 报告执行状态到TC。
- ② 二阶段
TC二阶段的工作：
Ⅰ TC检测各分支事务执行状态；
如果都成功，通知所有RM提交事务；
如果有失败，通知所有RM回滚事务。
RM二阶段的工作：
Ⅰ 接收TC指令，提交或回滚事务。
2、XA模式特点
- ① 优点
事务的强一致性，满足ACID原则；
常用数据库都支持，实现简单，并且没有代码侵入。
- ② 缺点
因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差；
依赖关系型数据库实现事务。
3、实现XA模式
- ① 修改application.yml配置文件
seata:
data-source-proxy-mode: XA # 开启数据源代理的XA模式
- ② 给发起全局事务的入口方法添加@GlobalTransactional注解
@Override
//@Transactional
@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();
- ③ 测试
五、Seata事务管理-AT模式
1、AT模式
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
- ① 阶段一
阶段一RM的工作：
Ⅰ 注册分支事务；
Ⅱ 记录undo-log（数据快照）；
Ⅲ 执行业务sql并提交；
Ⅳ 报告事务状态。
- ② 阶段二
阶段二提交时RM的工作：
Ⅰ 删除undo-log即可；
阶段二回滚时RM的工作：
Ⅰ 根据undo-log恢复数据到更新前。
2、AT模式预防脏写
- ① 全局锁写隔离
全局锁：由TC记录当前正在操作某行数据的事务，该事务持有全局锁，具备执行权。
- ② 全局锁锁表
关键记录：xid事务id、table_name表名、pk锁的行id等，该表给TC服务使用。
注意：仅受Seata管理的事务才会被全局锁管理。
-- ----------------------------
-- Table structure for lock_table
-- ----------------------------
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;
- ③ undo_log表
特殊的：非Seata管理的事务修改全局锁管理事务的数据，回滚时产生数据异常。
Seata处理方式：
Ⅰ 插入回滚日志：把前后镜像（afterImage、beforeImage）数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
Ⅱ 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。
该表给微服务使用。
-- ----------------------------
-- Table structure for 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;
-- ----------------------------
-- Records of undo_log
-- ----------------------------
3、AT模式特点
- ① 优点
Ⅰ 一阶段完成直接提交事务，释放数据库资源，性能比较好；
Ⅱ 利用全局锁实现读写隔离；
Ⅲ 没有代码侵入，框架自动完成回滚和提交。
- ② 缺点
Ⅰ 两阶段之间属于软状态，属于最终一致；
Ⅱ 框架的快照功能会影响性能，但比XA模式要好很多。
4、AT模式实现
- ① 准备TC全局锁锁表
导入lock_table，详见上方。
- ② 准备微服务undo_log表
导入undo_log，详见上方。
- ③ 修改application.yml配置文件
seata:
data-source-proxy-mode: AT # 开启数据源代理的AT模式
六、Seata事务管理-TCC模式
1、TCC模式
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。
把 自定义 的分支事务纳入到全局事务的管理中，TCC模式需要实现三个方法：
- ① Try：资源的检测和预留；
- ② Confirm：完成资源操作业务，要求 Try 成功 Confirm 一定要能成功；
- ③ Cancel：预留资源释放，可以理解为try的反向操作。
2、TCC模式特点
- ① 优点
Ⅰ 一阶段完成直接提交事务，释放数据库资源，性能好； Ⅱ 相比AT模型，无需生成快照，无需使用全局锁，性能最强； Ⅲ 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库。 - ② 缺点
Ⅰ 有代码侵入，需要人为编写Try、Confirm和Cancel接口，太麻烦； Ⅱ 软状态，事务是最终一致； Ⅲ 需要考虑Confirm和Cancel的失败情况，做好幂等处理。
3、TCC模式注意点
- ① 保证confirm、cancel接口的幂等性；
- ② 允许空回滚；
- ③ 拒绝业务悬挂。
空回滚：Try阶段阻塞，Cancel执行。
业务悬挂：Try阶段阻塞，Cancel执行，Try恢复后又执行，后续无Confirm/Cancel。
4、TCC模式实现
- ① 接口准备
Ⅰ 接口上使用@LocalTCC注解；
Ⅱ Try方法上使用@TwoPhaseBusinessAction注解，配置好Try、Confirm、Cancel方法；
Ⅲ 需要传递的参数使用@BusinessActionContextParameter注解配置；
Ⅳ Confirm、Cancel方法需要boolean返回值。
@LocalTCC
public interface AccountTCCService
@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
public void deduct(
@BusinessActionContextParameter(paramName = "userId") String userId,
@BusinessActionContextParameter(paramName = "money") int money
);
public boolean confirm(BusinessActionContext context);
public boolean cancel(BusinessActionContext context);
- ② 编写实现类
@Slf4j
@Service
public class AccountTCCServiceImpl implements AccountTCCService
@Autowired
private AccountMapper accountMapper;
@Autowired
private AccountFreezeMapper accountFreezeMapper;
... ...
- ③ 表格准备
Ⅰ account_tbl表
CREATE TABLE `account_tbl` (
`id` int NOT NULL AUTO_INCREMENT,
`user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
`money` int unsigned DEFAULT 0,
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb3 ROW_FORMAT=COMPACT;
Ⅱ account_freeze_tbl表
xid事务id、state事务状态、冻结资源、对应账户。
CREATE TABLE `account_freeze_tbl` (
`xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL,
`freeze_money` int unsigned DEFAULT 0,
`state` int DEFAULT NULL COMMENT 事务状态，0:try，1:confirm，2:cancel,
PRIMARY KEY (`xid`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 ROW_FORMAT=COMPACT;
- ④ 编写Try方法
Ⅰ 事务ID获取方法：String xid = RootContext.getXID();；
Ⅱ 防止悬挂操作：
// 【悬挂操作】判断freeze中是否有冻结记录，如果有，一定是CANCEL执行过，需要拒绝业务
AccountFreeze originFreeze = accountFreezeMapper.selectById(xid);
if (originFreeze != null)
// CANCEL执行过，需要拒绝业务
return;
完整方法体如下：
@Override
@Transactional
public void deduct(String userId, int money)
// 0. 获取事务id
String xid = RootContext.getXID();
// 【悬挂操作】判断freeze中是否有冻结记录，如果有，一定是CANCEL执行过，需要拒绝业务
AccountFreeze originFreeze = accountFreezeMapper.selectById(xid);
if (originFreeze != null)
// CANCEL执行过，需要拒绝业务
return;
// 1. 扣减可用余额
accountMapper.deduct(userId, money);
// 2. 记录冻结金额，事务状态
// 2.1 设置冻结金额信息
AccountFreeze freeze = new AccountFreeze();
freeze.setUserId(userId);
freeze.setFreezeMoney(money);
freeze.setState(AccountFreeze.State.TRY);
freeze.setXid(xid);
// 2.2 将信息写入数据库
accountFreezeMapper.insert(freeze);
- ⑤ 编写Confirm方法
@Override
public boolean confirm(BusinessActionContext context)
// 1. 获取事务id
String xid = context.getXid();
// 2. 根据事务id删除冻结金额
int count = accountFreezeMapper.deleteById(xid);
return count == 1;
- ⑥ 编写Cancel方法
Ⅰ 空回滚：
// 【空回滚】的判断，判断freeze对象是否为null，为null证明try没有执行，需要空回滚
if (freeze == null)
freeze = new AccountFreeze();
freeze.setUserId(userId);
freeze.setFreezeMoney(0);
freeze.setState(AccountFreeze.State.CANCEL);
freeze.setXid(xid);
accountFreezeMapper.insert(freeze);
return true;
Ⅱ 幂等：
// 【幂等】判断
if (freeze.getState() == AccountFreeze.State.CANCEL)
// 已经处理过一次CANCEL了，无需重复处理
return true;
完整方法体如下：
@Override
public boolean cancel(BusinessActionContext context)
// 0. 查询冻结记录
String xid = context.getXid();
String userId = context.getActionContext("userId").toString();
AccountFreeze freeze = accountFreezeMapper.selectById(xid);
// 【空回滚】的判断，判断freeze对象是否为null，为null证明try没有执行，需要空回滚
if (freeze == null)
freeze = new AccountFreeze();
freeze.setUserId(userId);
freeze.setFreezeMoney(0);
freeze.setState(AccountFreeze.State.CANCEL);
freeze.setXid(xid);
accountFreezeMapper.insert(freeze);
return true;
// 【幂等】判断
if (freeze.getState() == AccountFreeze.State.CANCEL)
// 已经处理过一次CANCEL了，无需重复处理
return true;
// 1. 恢复可用金额
accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
// 2. 将冻结金额清零，状态改为CANCEL
freeze.setFreezeMoney(0);
freeze.setState(AccountFreeze.State.CANCEL);
int count = accountFreezeMapper.updateById(freeze);
return count == 1;
七、Seata事务管理-Saga模式
1、Saga模式
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
2、Saga模式特点
- ① 优点
Ⅰ 一阶段提交本地事务，无锁，高性能；
Ⅱ 事件驱动架构，参与者可异步执行，高吞吐；
Ⅲ 补偿服务易于实现。
- ② 缺点
Ⅰ 不保证隔离性。
3、Saga模式实现
官方demo：GitHub - seata/seata-samples: seata-samples。
可以参考官方介绍：Seata Saga 模式。
八、Seata事务管理对比
模式 | XA | seata-分布式事务与seata |