Seata的架构以及实现过程详解，seata的XA、TCC、AT模式的一步步搭建和部署 ...

目录
 seata架构讲解
一、搭建TC服务和微服务集成Seata
1.1下载解压seata-server包
1.2修改Seata配置
1.3建立数据库以及对应的数据库表
1.4启动TC服务
 1.6将seata集成到微服务项目中
（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，下面提供建表语句

2. SET NAMES utf8mb4;
3. SET FOREIGN_KEY_CHECKS = 0;
5. -- ----------------------------
6. -- 分支事务表
7. -- ----------------------------
8. DROP TABLE IF EXISTS `branch_table`;
9. CREATE TABLE `branch_table`  (
10.   `branch_id` bigint(20) NOT NULL,
11.   `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
12.   `transaction_id` bigint(20) NULL DEFAULT NULL,
13.   `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
14.   `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
15.   `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
16.   `status` tinyint(4) NULL DEFAULT NULL,
17.   `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
18.   `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
19.   `gmt_create` datetime(6) NULL DEFAULT NULL,
20.   `gmt_modified` datetime(6) NULL DEFAULT NULL,
21.   PRIMARY KEY (`branch_id`) USING BTREE,
22.   INDEX `idx_xid`(`xid`) USING BTREE
23. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
25. -- ----------------------------
26. -- 全局事务表
27. -- ----------------------------
28. DROP TABLE IF EXISTS `global_table`;
29. CREATE TABLE `global_table`  (
30.   `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
31.   `transaction_id` bigint(20) NULL DEFAULT NULL,
32.   `status` tinyint(4) NOT NULL,
33.   `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
34.   `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
35.   `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
36.   `timeout` int(11) NULL DEFAULT NULL,
37.   `begin_time` bigint(20) NULL DEFAULT NULL,
38.   `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
39.   `gmt_create` datetime NULL DEFAULT NULL,
40.   `gmt_modified` datetime NULL DEFAULT NULL,
41.   PRIMARY KEY (`xid`) USING BTREE,
42.   INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
43.   INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
44. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
46. 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相关依靠 

1. <dependency>
2.     <groupId>com.alibaba.cloud</groupId>
3.     <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
4.     <exclusions>
5.         <!--版本较低，1.3.0，因此排除-->
6.         <exclusion>
7.             <artifactId>seata-spring-boot-starter</artifactId>
8.             <groupId>io.seata</groupId>
9.         </exclusion>
10.     </exclusions>
11. </dependency>
12. <!--seata starter 采用1.4.2版本-->
13. <dependency>
14.     <groupId>io.seata</groupId>
15.     <artifactId>seata-spring-boot-starter</artifactId>
16.     <version>${seata.version}</version>
17. </dependency>

复制代码

  

注意：

  

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

  seata-spring-boot-starter版本为1.3.0必要自行修改
  （2）配置application.yml，让微服务（我这里由于是同一个业务，所以三个模块服务都必要举行配置发现 ）通过注册中心找到seata-server（nacos服务注册中心对应的服务名）：

1. seata:
2.   registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
3.     # 参考tc服务自己的registry.conf中的配置
4.     type: nacos
5.     nacos: # tc
6.       server-addr: 127.0.0.1:8848
7.       namespace: ""
8.       group: DEFAULT_GROUP
9.       application: seata-server # tc服务在nacos中的服务名称
10.       cluster: default
11.       username: nacos
12.       password: nacos
13.   tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
14.   service:
15.     vgroup-mapping:
16.       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

1. CREATE TABLE `undo_log`  (
2.   `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
3.   `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
4.   `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',
5.   `rollback_info` longblob NOT NULL COMMENT 'rollback info',
6.   `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',
7.   `log_created` datetime(6) NOT NULL COMMENT 'create datetime',
8.   `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',
9.   UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
10. ) 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

1. CREATE TABLE `lock_table`  (
2.   `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
3.   `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
4.   `transaction_id` bigint(20) NULL DEFAULT NULL,
5.   `branch_id` bigint(20) NOT NULL,
6.   `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
7.   `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
8.   `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
9.   `gmt_create` datetime NULL DEFAULT NULL,
10.   `gmt_modified` datetime NULL DEFAULT NULL,
11.   PRIMARY KEY (`row_key`) USING BTREE,
12.   INDEX `idx_branch_id`(`branch_id`) USING BTREE
13. ) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
16. SET FOREIGN_KEY_CHECKS = 1;

复制代码

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

1. seata:
2.   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事务管理实行时分支事务的状态

1. CREATE TABLE `account_freeze_tbl`  (
2.   `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
3.   `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
4.   `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
5.   `state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
6.   PRIMARY KEY (`xid`) USING BTREE
7. ) 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方法都必要在接口中基于注解来声明，声明如下：

1. package cn.seata.account.service;
4. import io.seata.rm.tcc.api.BusinessActionContext;
5. import io.seata.rm.tcc.api.BusinessActionContextParameter;
6. import io.seata.rm.tcc.api.LocalTCC;
7. import io.seata.rm.tcc.api.TwoPhaseBusinessAction;
9. @LocalTCC
10. public interface AccountTCCService {
12.     /**
13.      * Try逻辑，@TwoPhaseBusinessAction中的name属性要与当前方法名一致，用于指定Try逻辑对应的方法
14.      */
15.     @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
16.     void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
17.                 @BusinessActionContextParameter(paramName = "money") int money);
19.     /**
20.      * 二阶段confirm确认方法、可以另命名，但要保证与commitMethod一致
21.      *
22.      * @param context 上下文,可以传递try方法的参数
23.      * @return boolean 执行是否成功
24.      */
25.     boolean confirm(BusinessActionContext context);
27.     /**
28.      * 二阶段回滚方法，要保证与rollbackMethod一致
29.      */
30.     boolean cancel(BusinessActionContext context);
31. }

复制代码

 注解解析：
@LocalTCC：标识为当前接口为TCC接口
@BusinessActionContextParameter(paramName = "userId")：通过这个注解可以将参数放在BusinessActionContest这个类的对象中（是一个上下文对象）由此可以举行数据传递，在try中举行接收后，可以在confirm和cancel中直接举行调用
serviceImpl层（重要逻辑代码）：

1. package cn.seata.account.service.impl;
4. import cn.seata.account.entity.AccountFreeze;
5. import cn.seata.account.mapper.AccountFreezeMapper;
6. import cn.seata.account.mapper.AccountMapper;
7. import cn.seata.account.service.AccountTCCService;
8. import io.seata.core.context.RootContext;
9. import io.seata.rm.tcc.api.BusinessActionContext;
10. import org.springframework.beans.factory.annotation.Autowired;
11. import org.springframework.stereotype.Service;
14. @Service
15. public class AccountTCCserviceImpl implements AccountTCCService {
17.     @Autowired
18.     AccountMapper accountMapper;
19.     @Autowired
20.     AccountFreezeMapper accountFreezeMapper;
22.     @Override
23.     public void deduct(String userId, int money) {
25.         //获取事务id
26.         String xid = RootContext.getXID();
27.         //悬挂处理，判断是否已经空回滚
28.         AccountFreeze freeze = accountFreezeMapper.selectById(xid);
29.         if (freeze != null)
30.         {
31.             return;
32.         }
33.         //扣减可用余额
34.         accountMapper.deduct(userId, money);
35.         //记录冻结金额，事务状态
36.         AccountFreeze accountFreeze = AccountFreeze.builder()
37.                 .xid(xid)
38.                 .state(AccountFreeze.State.TRY)
39.                 .userId(userId)
40.                 .freezeMoney(money)
41.                 .build();
42.         //插入数据
43.         accountFreezeMapper.insert(accountFreeze);
44.     }
46.     @Override
47.     public boolean confirm(BusinessActionContext context) {
48.         String xid = context.getXid();
49.         int deleteById = accountFreezeMapper.deleteById(xid);
50.         return deleteById == 1;
51.     }
53.     @Override
54.     public boolean cancel(BusinessActionContext context) {
55.         //查询冻结记录
56.         String xid = context.getXid();
57.         AccountFreeze accountFreeze = accountFreezeMapper.selectById(xid);
58.         //做空回滚判断
59.         if (accountFreeze == null) {
60.             accountFreeze = AccountFreeze.builder()
61.                     .xid(xid)
62.                     .state(AccountFreeze.State.CANCEL)
63.                     .userId(context.getActionContext("userId").toString())
64.                     .freezeMoney(0)
65.                     .build();
66.             accountFreezeMapper.insert(accountFreeze);
67.             return true;
68.         }
69.         //幂等判断,防止重复执行
70.         if (accountFreeze.getState() == AccountFreeze.State.CANCEL) {
71.             return true;
72.         }
73.         //恢复扣减余额
74.         accountMapper.refund(accountFreeze.getUserId(),accountFreeze.getFreezeMoney());
75.         //修改冻结数据
76.         accountFreeze.setFreezeMoney(0);
77.         accountFreeze.setState(AccountFreeze.State.CANCEL);
78.         accountFreezeMapper.updateById(accountFreeze);
79.         return true;
80.     }
81. }

复制代码

其余代码可以若有必要可以去我的gitee开源项目中举行查看seata-demo源码

https://gitee.com/cooldownxy/seata-demo
 4.3编写完成后，测试代码

这里就不再赘述，测试结果符合预期

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。