Seata的架构以及实现过程详解，seata的XA、TCC、AT模式的一步步搭建和部署，三种模式的特点详解，超详细，掌握seata一篇足矣

丘丘fighting

已于 2024-10-08 18:16:50 修改

阅读量518

点赞数 14

文章标签：分布式 java 微服务

于 2024-10-08 18:14:32 首次发布

本文链接：https://blog.csdn.net/weixin_64339548/article/details/142673471

版权

（1）在微服务的pom文件中引入seata相关依赖

（2）配置application.yml，让微服务（我这里因为是同一个业务，所以三个模块服务都需要进行配置发现）通过注册中心找到seata-server（nacos服务注册中心对应的服务名）：

二、搭建Seata的XA模式进行事务管理

2.1修改application.yml文件，开启XA模式

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

2.3重启服务并进行测试

三、搭建Seata的AT模式进行事务管理

3.1导入undo_log导入到服务关联的数据库中（这里我的服务关联的三张数据表在同一个数据库就只需要导入一次，读者请根据自己的服务关联状况进行表的导入）

3.2导入lock_table到TC关联的数据库中，用于TC服务记录全局锁

3.3修改业务中每个微服务的事务管理模式为AT模式

3.4重启服务完成测试

四、搭建seata的TCC模式进行事务管理

4.1设计预留资源表

4.2编写try、confirm以及cancel的业务功能代码

4.3编写完成后，测试代码

前言:

本文目的是介绍如何搭建部署seata并通过Seata实现维持分布式事务的一致性、原子性、隔离性、持久性（事务的ACID原则）完成seata提供的四种模式的实现过程和讲解不同模式的区别。以及我在本篇文章的适用的项目源码链接：seata-demo项目源码

seata架构讲解

前言(本块主要是理论讲解，需要具体操作代码的读者可通过目录自动跳转)：

什么是分布式事务？

        分布式事务：在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。

（当用户完成下单，订单数据数据库需要增加一条订单数据，用户数据库的账户记录表需要扣除对应用户的余额，库存数据库中对应的库存表也需要将对应的商品数量进行减少，多个服务构成了整个业务，但其中的服务可能因为某些原因而导致服务失败（如上述的库存不足，导致库存服务产生异常），这时我们需要回滚整个业务，使其达到最开始的状态，维持分布式事务的最终一致，如果都成功那么最终状态也是一致的）

在分布式事务中存在着最大的问题就是，如何保证各个子事务的一致性。BASE理论对CAP定理的解决思想，引出了解决问题的方法

CAP理论：1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致
Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
Partition tolerance （分区容错性）：网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。在集群出现分区时，整个系统也要持续对外提供服务

        但分布式系统无法同时满足这三个指标



而BASE理论是对CAP的一种解决思路，包含三个思想：

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

结合两种理论我们可以得到解决分布式事务一致性的两种模式：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态

得到了解决问题的模式和思路,那我们又怎么实现这两个模型呢？

        解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。

这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务

        而Seata又是怎么实现这个模型的呢？

        Seata事务管理中有三个重要的角色：

TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
（每一项微服务就是一个RM,一个业务的所有微服务就组成了TM,当业务发生时，由TC进行事务管理，记录每一个事务的状态（成功还是发生异常等状况），根据事务的状态判断是否提交事务，还是回滚事务，保证事务的一致性）

这里Seata针对分布式事务的处理提供了四种解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
TCC模式：最终一致的分阶段事务模式，有业务侵入
AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
SAGA模式：长事务模式，有业务侵入

一、搭建TC服务和微服务集成Seata

前言：

因为博主自身的项目使用的Spring Cloud Alibaba是2.2.5release版本所以使用的Seata对应版本是1.4.2,大家在使用Seata时注意选择与Spring Cloud Alibaba对应的版本，这是官方版本参考网址版本说明https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

1.1下载解压seata-server包

下载地址Apach Seata

1.2修改Seata配置

（1）修改conf目录下的registry.conf文件：

（2）修改结果

（3）配置Seata数据库相关设置

前言：这里博主为了方便以后做TC服务集群，共享同一个配置文件，所以需要先在nacos中编写对应的配置文件，如果不做TC服务集群配置可直接修改/seata/script/config-center/config.txt的配置文件，内容可参考以下，记得修改对应的数据库和账户密码

注意：

添加配置数据库启动项时，如果你是Mysql8.0及其以上的版本需要自行添加时区，参考如下，否则Mysql无法正常启动

# 数据存储方式，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&serverTimezone=GMT%2B8
store.db.user=root
store.db.password=1234
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

1.3建立数据库以及对应的数据库表

注意：

tc服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。我的数据库名称是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;

1.4启动TC服务

进入bin目录，运行其中的seata-server.bat即可，运行后可通过nacos进行校验是否配置成功

注意：

1、如果是通过nacos的配置中心配置的配置文件需要先将nacos打开，再启动seata

2、启动运行时发生以下报错

Caused by: java.lang.NullPointerException: null
at com.mysql.jdbc.ConnectionImpl.getServerCharset(ConnectionImpl.java:2989) ~[na:na]
at com.mysql.jdbc.MysqlIO.sendConnectionAttributes(MysqlIO.java:1873) ~[na:na]
at com.mysql.jdbc.MysqlIO.proceedHandshakeWithPluggableAuthentication(MysqlIO.java:1802) ~[na:na]
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1206) ~[na:na]
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2239) ~[na:na]
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2270) ~[na:na]

解决方法：

重新引入一个Mysql的jar包，可以在自己Maven本地仓库找到（如下图），然后粘贴复制放在seata的lib目录下（如图二），在进行重新启动

图二：

启动成功后会开放8091的服务端口

通过nacos的服务注册中心可以进行检测是否完成配置：

注意：

这里开放的8091端口不需要我们自己通过浏览器访问，而是之后配置的TM和RM进行访问的

1.6将seata集成到微服务项目中

前言：

我的微服务较为简单，主要是三个板块（订单支付、库存管理，个人账户管理），当完成一条订单插入数据时，如果数据合法，就需要将对应的个人账户的金额和库存进行减少，数据不合法要保证业务的事务性（因为三个模块操作的是不同的数据库表）

（1）在微服务的pom文件中引入seata相关依赖

<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>

注意：

自己的seata服务是什么版本就导入对应的依赖，我的是1.4.2版本它其中支持的

seata-spring-boot-starter版本为1.3.0需要自行修改

（2）配置application.yml，让微服务（我这里因为是同一个业务，所以三个模块服务都需要进行配置发现）通过注册中心找到seata-server（nacos服务注册中心对应的服务名）：

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-server # tc服务在nacos中的服务名称
      cluster: default
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping:
      seata-demo: default

定位nacos服务的需要声明（namespace+group+serviceName+cluster）

完成配置后，重启服务,可以观察seata-server的黑窗口发现服务注册的信息，表示为我们已经成功完成配置

二、搭建Seata的XA模式进行事务管理

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

而seata的XA模式进行事务管理则是实现了数据库的XA规范上提供的接口，总体分为两个阶段

第一个阶段是当业务发生时TM(事务管理器)会在TC中启动全局事务并通过TM作为入口，调用业务中的其他微服务作为分支，各个微服务被调用后进行服务注册到TC并通过RM进行事务管理,再开始执行各个分支任务（完成对不同的数据表的操作），操作完成后不提交而是向TC进行结果报告。

第二个阶段是TM发现每个分支任务都已经结束，于是向TC发起通知业务已经结束，TC就会开始检查分支事务状态，发现如果分支任务都已成功提交结果，且结果都是成功的，就开启事务提交，通知每一个分支服务提交数据库的操作结果，如果TC发现事务状态有失败的，就开全局事务额回滚，将每个分支事务的数据库操作进行回滚达到最开始的状态，保证数据库的一致性

优点：

1.XA模式中，开启执行业务后，其中任意一个分支任务完成数据库操作后不会进行提交，而是等待其他所有的分支业务完成后并提交操作结果，由TC服务进行检查后统一进行提交或者回滚，可以使整个业务达到强一致的状态和效果

2.同时，基本大部分数据库都支持XA规范，seta也是在其提供的接口进行了封装，本质还是调用数据库的XA相关方法实现事务管理，我们进行代码编写也就更加方便同时没有代码侵入

缺点：

1.由于分支事务之间的相互等待，而在等待的过程中，分支事务也一直霸占者数据库锁，会造成一定的性能损失

2.如果数据库本身不支持XA规范，这种模式将无法进行应用，如redis

2.1修改application.yml文件，开启XA模式

注意：整个业务的每一个微服务都需要进行配置，开启XA模式

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

2.3重启服务并进行测试

（1）访问入口微服务的接口，传输合格的数据

（2）分支事务成功完成并提交业务操作

（3）提交不规范的数据（扣款金额大于个人账户所有的金额）

(4)程序返回错误结果，但分支事务完成了统一回滚，库存数量并未减少，订单并未增加，扣款失败

（5）测试完成已成功搭建XA并对业务进行了统一事务管理

三、搭建Seata的AT模式进行事务管理

AT模式模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

AT模式与XA模式的区别：

1.在第一阶段在分支事务进行数据库操作前后会对修改的数据进行备份记录生成一份数据快照（undo log）

2.在第一节阶段，分支事务完成数据库的操作后将会直接进行提交，释放数据库锁

3.在第二阶段，TC检查分支事务的状态时，每一个都已成功完成，则进行提交，每个分支事务将会删除对应生成的数据库快照，如果，TC发现某一个事务的提交状态失败，则进行回滚操作，通知每个分支事务根据生成的数据库快照完成数据表的数据恢复，达到最终一致性的效果

AT模式存在的脏写问题:

脏写问题：AT模式中，在第一阶段某一个分支事务完成数据库操作后（比如我的个人账户原来有1000，现在将我的个人账户的余额减少了100元，变成了900），就直接提交了，同时释放了数据库锁，高并发的情况下，同时又有一个数据库操作（第二次操作）我的个人账户又减少100元（我现在的余额为800），并且成功提交，但第一次操作数据库的那个分支事务因为其他原因需要进行回滚，于是这个分支事务根据自己操作前备份的数据库快照完成数据库的恢复对我的余额进行恢复又变成了最开始的状态（1000）这就导致了数据库的脏写问题

AT模式针对脏写问题的解决：

AT模式中引入了一个全局锁的概念，它是由TC进行操作和管理，TC会对分支事务的操作的数据库资源（针对的就是修改的具体哪一张表的哪些个单元格）进行记录，并保存到数据库中的一张表中，当分支事务要执行数据库操作时，TC就会记录操作的数据库资源，在完成全局事务提交或者回滚之前进行，进行资源锁定，在锁定期间，如果有其他的数据库操作（由seata进行事务管理），需要操作这张表的数据，只要不是已经被全局锁管理的数据将会被放行，反之则会要求进行等待业务完成后，释放全局锁之后再进行操作，同时全局锁作用的范围很小(针对某些单元格)，所以他造成的性能影响是比较低的。

同时上面还存在极端情况就是，在锁定期间有其他数据库操作且不是由seata进行事务管理，它可以直接进行对数据库的数据进行操作并提交（假设修改的就是全局锁锁定的资源），这时也会导致数据的脏写问题，但AT的第一阶段中在完成对数据库的操作后会再生成一份修改后的数据库快照，当业务需要回滚时，会将数据库的数据与修改后的快照数据进行对比，发现数据不一致，就说明数据已经被其他人修改，这时就无法成功完成回滚操作，同时报出错误信息，提示程序员数据库的信息不一致，可能发生了恶意篡改

3.1导入undo_log导入到服务关联的数据库中（这里我的服务关联的三张数据表在同一个数据库就只需要导入一次，读者请根据自己的服务关联状况进行表的导入）

建表语句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;

3.2导入lock_table到TC关联的数据库中，用于TC服务记录全局锁

建表语句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;

3.3修改业务中每个微服务的事务管理模式为AT模式

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

3.4重启服务完成测试

测试数据：提交范围内的库存，超出余额的金额

预测结果：因为余额不存导致订单无法新增，库存不减

实际结果：返回错误信息，数据库数据保持了一致性，符合测试预期

四、搭建seata的TCC模式进行事务管理

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；
Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。
Cancel：预留资源释放，可以理解为try的反向操作。

在资源预留阶段的过程中，分支事务依旧是完成数据库操作，不同AT模式的是它不存在全局锁也不需要生成快照，操作数据库后直接释放数据库锁，但是在操作数据库前会进行资源预留，也就是记录资源（比如我的库存修改前有100件，需要减少10件，这里记录资源记录的就是扣除的件数10件），当需要回滚时，就将预留的资源再加回到扣除的资源上（加回我扣除的10件）达到最终一致的效果，并将记录的预留数据进行删除。

由于TCC事务管理的特性，它实现事务管理不依赖于数据库，而是依赖补偿操作，所以可以用于非事务型数据库如，redis，同时，由于需要自己认为编写try，confirm和cancel接口，具有代码侵入性，同时需要考虑Confirm和Cancel的失败情况导致的幂处理问题，要求代码健壮性高。同时，并不是所有事务都适用TCC事务管理，一般是需要对数据进行增加和减少，需要进行资源预留时，才进行使用，而且TCC模式可以与其他模式进行混合使用，所以可以只针对某些要求较高且适用的额事务进行TCC模式，这里我对我的微服务项目中的金额进行TCC模式事务管理，完成当用户下单后，我的金额进行对应的减少。

所以我的微服务将如下进行设计

try业务：添加冻结金额，扣减可用金额，也就是预留资源
confirm业务：删除冻结金额
cancel业务：删除冻结金额，恢复可用金额
保证confirm、cancel接口的幂等性（指我的这两个功能代码在一个业务中，被调用多次也不会影响的数据最终一致性，可以通过判断该功能是否已经执行过，执行过了，就不在执行）
允许空回滚：
拒绝业务悬挂

空回滚：当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

比如我的一个业务因为某些原因进行阻塞，而没有执行try操作，同时也超时了，引发了全局事务的回滚操作，但是我这个事务因为没有进行tyr操作所以不能直接执行cancel操作否则可能会引述数据错误（比如我还开始预留我的金额，减少我的金额，就要开始对我的金额进行恢复，而此时，我的预留金额为空，所以直接恢复将会发生错误），所以我们需要定义一个空的回滚操作，去解决当前发生的问题

业务悬挂：对于已经空回滚的业务，如果以后继续执行try（因为之前是因为阻塞而无法执行导致的超时，但是不代表try任务无法执行，在阻塞之后try任务会接着执行），就永远不可能confirm或cancel，因为现在业务已经结束了（阶段二已经结束了），这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂。

解决业务悬挂的方法：在进行try、cancel、confirm时记录当前的事务状态，从而判断是否需要做空回滚和避免业务悬挂

4.1设计预留资源表

用于保存预留的资源，作为数据恢复时适用，以及保存TCC事务管理执行时分支事务的状态

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 NULL DEFAULT NULL,
  `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
  `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;

4.2编写try、confirm以及cancel的业务功能代码

service层提供try、confirm以及cancel的接口，因为TCC的Try、Confirm、Cancel方法都需要在接口中基于注解来声明，声明如下：

package cn.seata.account.service;


import io.seata.rm.tcc.api.BusinessActionContext;
import io.seata.rm.tcc.api.BusinessActionContextParameter;
import io.seata.rm.tcc.api.LocalTCC;
import io.seata.rm.tcc.api.TwoPhaseBusinessAction;

@LocalTCC
public interface AccountTCCService {

    /**
     * Try逻辑，@TwoPhaseBusinessAction中的name属性要与当前方法名一致，用于指定Try逻辑对应的方法
     */
    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money") int money);

    /**
     * 二阶段confirm确认方法、可以另命名，但要保证与commitMethod一致
     *
     * @param context 上下文,可以传递try方法的参数
     * @return boolean 执行是否成功
     */
    boolean confirm(BusinessActionContext context);

    /**
     * 二阶段回滚方法，要保证与rollbackMethod一致
     */
    boolean cancel(BusinessActionContext context);
}

注解解析：

@LocalTCC：标识为当前接口为TCC接口

@BusinessActionContextParameter(paramName = "userId")：通过这个注解可以将参数放在BusinessActionContest这个类的对象中（是一个上下文对象）由此可以进行数据传递，在try中进行接收后，可以在confirm和cancel中直接进行调用

serviceImpl层（主要逻辑代码）：

package cn.seata.account.service.impl;


import cn.seata.account.entity.AccountFreeze;
import cn.seata.account.mapper.AccountFreezeMapper;
import cn.seata.account.mapper.AccountMapper;
import cn.seata.account.service.AccountTCCService;
import io.seata.core.context.RootContext;
import io.seata.rm.tcc.api.BusinessActionContext;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;


@Service
public class AccountTCCserviceImpl implements AccountTCCService {

    @Autowired
    AccountMapper accountMapper;
    @Autowired
    AccountFreezeMapper accountFreezeMapper;

    @Override
    public void deduct(String userId, int money) {

        //获取事务id
        String xid = RootContext.getXID();
        //悬挂处理，判断是否已经空回滚
        AccountFreeze freeze = accountFreezeMapper.selectById(xid);
        if (freeze != null)
        {
            return;
        }
        //扣减可用余额
        accountMapper.deduct(userId, money);
        //记录冻结金额，事务状态
        AccountFreeze accountFreeze = AccountFreeze.builder()
                .xid(xid)
                .state(AccountFreeze.State.TRY)
                .userId(userId)
                .freezeMoney(money)
                .build();
        //插入数据
        accountFreezeMapper.insert(accountFreeze);
    }

    @Override
    public boolean confirm(BusinessActionContext context) {
        String xid = context.getXid();
        int deleteById = accountFreezeMapper.deleteById(xid);
        return deleteById == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext context) {
        //查询冻结记录
        String xid = context.getXid();
        AccountFreeze accountFreeze = accountFreezeMapper.selectById(xid);
        //做空回滚判断
        if (accountFreeze == null) {
            accountFreeze = AccountFreeze.builder()
                    .xid(xid)
                    .state(AccountFreeze.State.CANCEL)
                    .userId(context.getActionContext("userId").toString())
                    .freezeMoney(0)
                    .build();
            accountFreezeMapper.insert(accountFreeze);
            return true;
        }
        //幂等判断,防止重复执行
        if (accountFreeze.getState() == AccountFreeze.State.CANCEL) {
            return true;
        }
        //恢复扣减余额
        accountMapper.refund(accountFreeze.getUserId(),accountFreeze.getFreezeMoney());
        //修改冻结数据
        accountFreeze.setFreezeMoney(0);
        accountFreeze.setState(AccountFreeze.State.CANCEL);
        accountFreezeMapper.updateById(accountFreeze);
        return true;
    }
}

其余代码可以若有需要可以去我的gitee开源项目中进行查看seata-demo源码https://gitee.com/cooldownxy/seata-demo