SpringCloud（12）— 分布式事务（Seata）
一 事务基础
1.事务的ACID原则
2.分布式事务问题
在分布式系统下，一个业务跨越多个服务或数据源，每一个服务都是一个事务。
要保证所有分支事务的最终状态一致，这样的事务就是分布式事务
3.讨论内容
二 理论基础
1.CAP定理
1998年由加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：
- Consistency（一致性）
- Availability（可用性）
- Partition tolerance（分区容错性）
Eric Brewer指出，分布式系统无法同时满足以上三个指标。这个结论叫做CAP定理。
1.Consistency（一致性）
用户访问分布式系统中的任意节点，得到的数据必须一致。
2.Availability（可用性）
用户访问集群中的任意健康节点，必须能够得到响应，而不是拒绝或超时。
3.Partition tolerance（分区容错性）
分区：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区。
容错：在集群出现分区时，整个系统也要对外提供服务。
4.小结
分布式系统通过网络连接，一定会出现分区问题（P）
当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
以Elasticsearch集群为例，当集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其他节点，保证数据的一致。因此Elasticsearch是低可用，高一致性，属于CP。
2.BASE理论
BASE理论是对CAP的一种解决思路，主要包含三个思想：
- Basically Available（基本可用）：分布式系统出现故障时，允许损失部分可用性，即保证核心可用
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时性的不一致状态
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是软状态结束后，最终达到数据的一致性
分布式最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论去解决这些问题
- AP模式：各个子事务分别执行和提交，允许出现结果不一致，然后采取弥补措施恢复数据即可，最终实现
一致性 - CP模式：各个子事务执行后相互等待，同时提交，同时回滚，达成
强一致性，但事务等待过程中，处于弱可用状态
3.分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证一致性。因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。
这里的子系统事务，称之为分支事务，有关联的各个分支事务在一起称之为全局事务。
三 Seata的使用
Seata是蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案，致力于提高性能和简单易用的分布式事务服务。为用户打造一站式的分布式事务解决方案。
Seata官网：Seata
1.Seata架构
Seata事务管理中有三个重要角色：
- TC（Transaction Coordinator）：事务协调者，维护全局和分支事务的状态，协调全局事务提交或回滚
- TM（Transaction Manager）：事务管理者，定义全局事务的范围，开始全局事务，提交或回滚全局事务
- RM（Resource Manager）：资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
Seata提供了四种不同的分布式事务解决方案：
- XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务入侵
- TCC模式：最终一致的分阶段事务模式，有业务入侵
- AT模式：最终一致的分阶段事务模式，无业务入侵，也是
Seata的默认模式 - SAGA模式：长事务模式，有业务入侵
2.部署Seata的TC
Seata的架构中有三个角色，分别为TC,TM和RM，其中的TM和RM其实是对业务的管理和代理
而TC是脱离业务之外的独立服务，需要去协调TM（全局事务）和RM（分支事务）
Seata的TC服务下载地址：https://github.com/seata/seata/releases
笔者编辑此文档时使用的版本为seata-server-1.4.2
1.编辑registry.conf
下载解压完成之后，找到 /conf/registry.conf,将seata-server服务注册到注册中心，笔者这里使用的是nacos,具体的配置信息科参考官网。
以下是一个简单的配置示例：
#配置注册中心，此处使用 nacos 作为注册中心
registry {
type = "nacos"
nacos {
application = "seata-server"
serverAddr = "127.0.0.1:8848"
group = "SEATA_GROUP"
namespace = ""
cluster = "default"
username = "nacos"
password = "nacos"
}
}
#统一配置，此处使用 nacos 作为统一配置
config {
type = "nacos"
nacos {
serverAddr = "127.0.0.1:8848"
namespace = ""
group = "SEATA_GROUP"
username = "nacos"
password = "nacos"
dataId = "seataServer.properties"
}
}
2.添加seataServer.properties
在 nacos 配置中心添加 seataServer.properties文件
配置内容如下：
主要配置了存储方式为db,且使用mysql数据库和mysql数据库的基本信息
# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?serverTimezone=Asia/Shanghai&characterEncoding=utf8
store.db.user=root
store.db.password=123456
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
3.创建数据库
mysql数据库seata的内容如下：
主要用来记录全局事务和分支事务
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;
4.运行服务
运行/bin/seata-server.bat文件来启动seata-server，linux系统使用/bin/seata-server.sh
启动完成后即可在nacos看到名为seata-server的服务
2.1 部署新版Seata的TC服务
笔者这里使用编辑时的最新版seata-server1.6.1
新版提供了UI界面以及新的配置文件格式。
新版的seata配置文件使用了 yaml格式，配置文件为/conf/application.yml,并且提供了示例文件/conf/application.example.yml
1.配置application.yml
以下是配置文件的简单示例：
server:
# 设置seata服务的访问端口
port: 7091
spring:
application:
# 设置seata服务的微服务名称
name: seata-server
console:
# 设置seata服务的登录用户名及密码
user:
username: seata
password: 123456
seata:
# 配置微服务信息，可参考提供的示例文件
config:
type: nacos
nacos:
server-addr: 127.0.0.1:8848
namespace:
group: SEATA_GROUP
username: nacos
password: nacos
context-path:
data-id: seataServer.properties
# 配置注册中心相关信息，可参考提供的示例文件
registry:
type: nacos
preferred-networks: 30.240.*
nacos:
application: seata-server
server-addr: 127.0.0.1:8848
group: SEATA_GROUP
namespace:
cluster: default
username:
password:
context-path:
store:
# 配置数据存储信息，这里使用了 db 存储，更多可参考提供的示例文件
mode: db
db:
datasource: druid
db-type: mysql
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/seata?rewriteBatchedStatements=true
user: root
password: 123456
min-conn: 10
max-conn: 100
global-table: global_table
branch-table: branch_table
lock-table: lock_table
distributed-lock-table: distributed_lock
query-limit: 1000
max-wait: 5000
security:
secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017
tokenValidityInMilliseconds: 1800000
ignore:
urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/api/v1/auth/login
2.创建数据库
新版本的seata提供了对应的数据库文件，位于 /script/server/db下
我们这里使用了 mysql数据库，所以使用/script/server/db/mysql.sql这个文件。
根据实际使用情况，使用对应的数据库文件即可。
3.运行服务
运行服务和旧版本一样，运行/bin/seata-server.bat文件来启动seata-server，linux系统使用/bin/seata-server.sh
运行成功以后，使用浏览器打开 localhost:7091来访问seata后台，这里的端口号根据自己的实际情况来即可
http://localhost:7091
然后就可以看到seata的后台，数据配置文件中的账号密码访问即可。
3.微服务集成
1.引入坐标
在微服务中引入seata的maven坐标
<!--引入Seata-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<exclusions>
<!--移除spring-cloud-starter-alibaba-seata中的低版本seata-->
<exclusion>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<!--这里的版本与seata的TC服务版本保持一致-->
<version>1.4.2</version>
</dependency>
2.修改项目配置文件
修改配置文件application.yml，让微服务通过注册中心去找到seata-server
seata:
registry:
nacos:
server-addr: localhost:8848
namespace: ""
group: SEATA_GROUP
#TC服务在nacos中的服务名称
application: seata-server
username: nacos
password: nacos
type: nacos
# 事务组，根据事务组获取TC服务的集群名称
tx-service-group: seata-demo
service:
vgroup-mapping:
#映射default（默认集群名称）到事务组
seata-demo: default
重启微服务，将微服务注册到seata，留意seata的日志，给出提示说明配置已经生效
3.小结
seata根据事务组的名称，去查找指定的集群
通过 tx-service-group定义事务组名称
通过vgroup-mapping映射指定的事务组到指定的集群
seata客户端事务组和集群的映射实现原理：以tx-service-group的值作为key，去vgroup-mapping中查找映射关系
四 XA模式
1.XA模式原理
XA模式是强一致性分阶段事务模式，牺牲了一定的可用性，无业务入侵
XA规范是 X/Open 组织定义的分布式事务处理（DTP）标准，XA规范描述了全局的TM与局部的RM之间的接口，几乎主流的的数据库都对XA规范提供了支持
XA模式的执行过程：
1.多个RM共同执行，执行完成之后（prepare）告知事务协调者已经执行完成（ready），等到事务协调者发起通知时多个RM再一起提交（commit）
2.多个RM共同执行，执行完成之后（prepare）告知事务协调者已经执行完成（ready），但是如果事务协调者收到某个RM的失败消息，则会通知所有参与事务的RM全部回滚
注意：单个RM的回滚是利用数据库本事的事务回滚功能实现
2.Seata的XA模式
seata中的XA模式基于XA模式原理做了一些调整
RM一阶段的工作：
- 注册分支事务（RM）到
TC - 执行分支业务但是不提交
- 报告执行状态到
TC
TC二阶段的工作：
- 检查各分支事务的执行状态
- 如果都成功，则通知所有RM提交事务
- 如果都失败，则通知所有RM回滚事务
RM二阶段的工作：接受TC的指令，提交或回滚事务
3.XA模式优缺点
优势：
- 强一致性：各个RM之间相互等待，一同提交或回滚，具有强一致性，保证了数据的同步和完整，满足ACID原则
- 容易实现：绝大部分主流数据库已经实现了单个事务的功能，基于这些数据库去实现XA模式变得比较容易
缺点：
- 可用性低：RM较多或某个RM耗时较长时，其他已执行完成的RM必须等待（占据数据库锁），造成了资源的浪费
- 依赖性强：过度依赖于数据库的事务功能，如果某个数据库不提供事务功能（例如Redis），则无法使用XA模式
4.SpringBoot实现XA
在微服务项目的配置文件中指定seata的模式为XA
每个参与事务的微服务项目都需要配置seata模式
seata:
data-source-proxy-mode: XA
在发起全局事务的入口方法上添加 @GlobalTransactional 注解
实现示例：当扣款失败时，生成的订单将不会被提交
@Autowired
private IUserCardClientFeign userCardClientFeign;
@GetMapping("/create")
@GlobalTransactional
public Boolean create(@RequestParam("userid") Integer userId) {
Order order = new Order();
// build object
DeductMoneyVo deductMoneyVo = new DeductMoneyVo();
// build object
//1.生成订单
boolean save = orderService.save(order);
//2.扣款
boolean deduct = userCardClientFeign.deductMoney(deductMoneyVo);
//3.扣减库存
return save;
}
五 AT模式
1.AT模式原理
AT模式同样是分阶段的事务模型，AT模式弥补了XA模式中资源锁定周期过长的缺陷
阶段一RM的工作：
- 注册分支事务
- 记录
undo-log（数据快照） - 执行业务sql并且提交
- 报告业务状态
阶段二RM的工作：
- 成功时删除
undo-log（数据快照）即可 - 失败时先使用
undo-log（数据快照）恢复数据，再删除undo-log（数据快照）
AT模式与XA模式的最大区别：
XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源XA模式依赖数据库机制实现回滚，AT模式利用数据快照实现数据回滚XA模式为强一致；AT模式则为最终一致
2.脏写问题和全局锁
AT模式由于直接提交数据，提前释放了数据库资源，这导致了在并发访问的情况下会存在一些安全问题。
例如：并发情况下，A事务的A1子事务执行完成释放了数据库资源，B事务的B1子事务此时就可以获取A1子事务释放的资源并且修改。此时如果A事务的A2子事务执行失败，那么A事务会回滚。这就会导致B事务的B1子事务操作丢失。
为解决AT模式的脏写问题，AT模式引入了全局锁的概念。
全局锁：由TC服务记录当前正在操作的某行数据的事务，该事务持有
全局锁，具备执行权
由TC服务提供全局锁，防止在操作期间其他事务再次修改数据。
加入全局锁之后的AT模式与XA模式类似，但实际上存在着一定差别：
- 全局锁由TC提供
- 粒度小：资源锁定期间，其他事务仍然可以读写该资源未被锁定的部分，例如以上示例，全局锁只是锁定了该行数据的
money字段，锁定期间该行数据的其他字段仍然可以被读写
极端情况下，如果是一个未被TC所管理的事务来读写有全局锁的数据，仍然有可能出现脏写问题。
AT模式在保存快照时保存了两份快照，分别是更新前和更新后，在AT模式第二阶段发生回滚时会进行比对，如果比如失败，则可以知道在AT模式第一阶段和AT模式第二阶段之间数据发生了更新，此时则需要人工介入。
3.AT模式优缺点
优点：
AT模式第一阶段完成直接提交，释放数据库资源，性能较好- 利用
全局锁实现读写隔离 - 没有代码入侵，整个过程由TC自动完成
缺点：
AT模式第一阶段和AT模式第二阶段之间属于软状态，属于最终一致- TC的快照功能会影响性能，但仍然优于
XA模式
4.SpringBoot实现AT
导入Mysql数据表
undo_log表导入到与微服务关联的数据库，用于记录快照信息
lock_table表导入到与TC服务关联的数据，用于记录全局锁
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- 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
-- ----------------------------
-- ----------------------------
-- 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;
SET FOREIGN_KEY_CHECKS = 1;
修改seata模式为AT
seata:
data-source-proxy-mode: AT
重启微服务进行测试。
六 TCC模式
1.TCC模式原理
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
- Try：资源的检测和预留
- Confirm：完成资源操作业务，要求Try成功则Confirm一定要能成功
- Cancel：预留释放，可以理解为Try的反向操作
阶段一（try）:
检查数据是否符合业务逻辑，例如余额是否充足，库存是否足够等。如果余额充足。如果满足业务逻辑则预留要扣减的金额或库存。
预留是通过冻结来实现的
阶段二（Confirm）:
如果阶段一（try）已经全部成功，则阶段二（Confirm）直接提交即可，提交时扣减被阶段一（try）冻结的资源。
阶段二（Cancel）:
如果阶段一（try）没有全部成功，则回滚数据；回滚时扣减被冻结的资源，增加到可用资源上。
TCC模式进入第二阶段后，不论是提交还是回滚，操作的都是第一阶段预留的资源
TCC模式的特点：
TCC模式属于最终一致，因为第一阶段和第二阶段之间存在软状态TCC模式无需加锁，主要依赖于业务逻辑，提前预留资源，事物之间不相互影响，性能优于AT模式TCC模式各阶段的实现需要人工编写
2.空回滚和业务悬挂
空回滚：当分支事务的try阶段阻塞时，可能导致全局事务超时而出发二阶段的cancel操作。在未执行try操作时执行了cancel操作，这时cancel不能做回滚，就是空回滚
业务悬挂：
对于已经回滚的业务，如果继续执行try，就永远不会confirm或者cancel，这就是业务悬挂；
应当阻止空回滚后的 try 操作，避免业务悬挂
3.TCC模式优缺点
优点：
- 一阶段完成，直接提交事务，释放数据库资源，性能好
- 相比
AT模式，无需生成快照，无需使用全局锁，性能最强 - 不依赖于
数据库事务，而是依赖于补偿操作，可以用于非事务性数据库
缺点：
- 有代码入侵，需要人为编写
try,confirm,cancel接口 - 存在软状态，事务是最终一致
- 需要考虑
confirm和cancel的失败情况，做好幂等处理
幂等：在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同
4.SpringBoot实现TCC
注意：不是所有业务都适合TCC模式，一般情况下使用在扣减业务中，典型的使用场景有扣减库存，扣减余额等
在seata中，AT模式与TCC模式可以混合使用。因为它们都被seata所管理且都是分阶段模式
以下示例：创建订单时扣款，扣减库存。其中扣减库存使用TCC模式实现
1.准备数据表
准备good_freeze表，用于存储TCC模式下的事务信息，以实现空回滚，防止业务悬挂，以及幂等性要求。
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- Table structure for “good_freeze”
-- ----------------------------
DROP TABLE IF EXISTS `good_freeze`;
CREATE TABLE `good_freeze` (
`xid` varchar(255) NOT NULL COMMENT '事务ID',
`good_id` bigint NULL DEFAULT NULL COMMENT '商品id',
`freeze_stock` bigint UNSIGNED NULL DEFAULT 0 COMMENT '冻结库存',
`state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;
SET FOREIGN_KEY_CHECKS = 1;
2.实现各阶段业务
- Try：记录冻结金额和事务到
good_freeze表；扣减good表的可用库存 - Confirm：根据
事务ID（xid）删除good_freeze的记录 - Cancel：修改
good_freeze表的冻结库存为0，state为2；修改good表，恢复可用库存 - 判断空回滚：根据
事务ID（xid）查询good_freeze表，如果未查到则需要空回滚 - 避免业务悬挂：
Try业务中，根据事务ID（xid）查询good_freeze表，如果存在则证明Cancel已经执行，拒绝执行Try
3.实现各阶段代码
1.TCC模式中的Try，Confirm，Cancel方法都需要在接口中基于注解来声明：
@LocalTCC
public interface GoodTCCService {
/**
* Try逻辑：@TwoPhaseBusinessAction中的 name 属性要与当前方法名一致，用于指定 try 逻辑所对应的方法
* @param goodId 商品ID
* @param num 冻结库存
*/
@TwoPhaseBusinessAction(name = "deductStock",commitMethod = "confirm",rollbackMethod = "cancel")
void deductStock(@BusinessActionContextParameter(paramName = "goodId") Long goodId,
@BusinessActionContextParameter(paramName = "num") Long num);
/**
* 二阶段 confirm 确认方法，可以重命名，但要保证和 commitMethod 保持一致
* @param context 业务上下文，可以传递 try 方法的参数
* @return
*/
boolean confirm(BusinessActionContext context);
/**
* 二阶段 cancel 回滚方法，可以重命名，但要保证和 rollbackMethod 保持一致
* @param context 业务上下文，可以传递 try 方法的参数
* @return
*/
boolean cancel(BusinessActionContext context);
}
- @LocalTCC：指明这是一个
TCC模式的接口类 - commitMethod： 定义二阶段
confirm确认方法 - rollbackMethod：定义二阶段
cancel回滚方法 - @BusinessActionContextParameter：整个
TCC模式中需要用到的参数，可以通过该注解来传递；被标记的参数会放到上下文中 - @TwoPhaseBusinessAction：该注解加在哪个方法上，就以哪个方法作为
Try
2.编写 good_freeze表的实体类，数据访问层代码，基于Mybatis-plus实现
3.GoodMapper.java中编写，扣减库存和返回库存的逻辑
@Mapper
public interface GoodMapper extends BaseMapper<Good> {
/**
* 扣减库存
*/
@Update("update tb_good set num=num-${num} where id=#{id}")
int deduct(@Param("num") Long num, @Param("id") Long id);
/**
* 返还库存
*/
@Update("update tb_good set num=num+${num} where id=#{id}")
int refund(@Param("num") Long num, @Param("id") Long id);
}
4.实现GoodTCCService接口
@Service
public class GoodTCCServiceImpl implements GoodTCCService {
@Autowired
private GoodFreezeMapper goodFreezeMapper;
@Autowired
private GoodMapper goodMapper;
@Override
public void deductStock(Long goodId, Long num) {
//获取事务ID
String xid = RootContext.getXID();
GoodFreeze freeze = goodFreezeMapper.selectById(xid);
if (Objects.nonNull(freeze)) {
// 存在记录，说明已经执行过，则不再执行业务
return;
}
//1.扣减可用余额
goodMapper.deduct(num, goodId);
//2.冻结库存,事务状态
GoodFreeze goodFreeze = new GoodFreeze();
goodFreeze.setFreezeStock(num);
goodFreeze.setGoodId(goodId);
goodFreeze.setState(GoodFreeze.State.TRY);
goodFreeze.setXid(xid);
goodFreezeMapper.insert(goodFreeze);
}
@Override
public boolean confirm(BusinessActionContext context) {
//1.获取事务ID
String xid = context.getXid();
//2.根据事务ID删除冻结记录
int count = goodFreezeMapper.deleteById(xid);
return count == 1;
}
@Override
public boolean cancel(BusinessActionContext context) {
//0.从数据中读取冻结信息
String xid = context.getXid();
GoodFreeze goodFreeze = goodFreezeMapper.selectById(xid);
if (Objects.isNull(goodFreeze)) {
// try 未执行，需要空回滚
//1.记录空回滚记录,从上下文中获取冻结的库存和商品ID
Long num = context.getActionContext("num", Long.class);
Long goodId = context.getActionContext("goodId", Long.class);
goodFreeze = new GoodFreeze();
goodFreeze.setXid(xid);
goodFreeze.setGoodId(goodId);
goodFreeze.setFreezeStock(0L);
goodFreeze.setState(GoodFreeze.State.CANCEL);
goodFreezeMapper.insert(goodFreeze);
return true;
}
// 1.判断幂等,解决业务悬挂
if (GoodFreeze.State.CANCEL.equals(goodFreeze.getState())) {
//已经处理，无需重复处理
return true;
}
//2.恢复可用金额
goodMapper.refund(goodFreeze.getFreezeStock(), goodFreeze.getGoodId());
//3.将冻结库存清理，修改冻结状态为cancel
goodFreeze.setFreezeStock(0L);
goodFreeze.setState(GoodFreeze.State.CANCEL);
int update = goodFreezeMapper.updateById(goodFreeze);
return update == 1;
}
}
- 使用
RootContext.getXID()获取当前事务线程的xid - 使用
BusinessActionContext对象 获取当前事务线程的xid
5.Controller代码示例
@GetMapping("/create")
@GlobalTransactional
public Boolean create(@RequestParam("userid") Integer userId, @RequestParam("good") Long goodId) {
try {
//假设库存为1,每次扣减1个库存
Integer num=1;
//1.获取商品信息
Good good = goodService.getById(goodId);
//2.构建订单并且生成
Order order = new Order();
order.setName(good.getName());
order.setNum(num);
order.setPrice(good.getPrice());
order.setUserId(userId);
order.setGoodId(goodId);
boolean save = orderService.save(order);
//3.扣款
DeductMoneyVo deductMoneyVo = new DeductMoneyVo();
deductMoneyVo.setDeductMoney(good.getPrice());
deductMoneyVo.setNumber("10001");
deductMoneyVo.setUserId(1);
boolean deduct = userCardClientFeign.deductMoney(deductMoneyVo);
//4.扣减库存
goodTCCService.deductStock(goodId,Long.valueOf(num));
return save;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
七 SAGA模式
Saga模式是seata提供的长事务解决方案。也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功什么都不做；失败通过编写补偿事务回滚
Saga模式优点：
- 事务参与者可以基于事件驱动去实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写
TCC模式的三个阶段，实现简单
Saga模式缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
Saga模式使用场景较少，此处不做详细探讨
八 四种模式对比
完结撒花！！！
974
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
