Seata TCC模式实战

红太狼 2023-01-16 11:11 164阅读 0赞

# 前言 #

最近状态有点不好，所以创作动力不足，发觉日常生活一定要做减法，对少量的事保持持续专注的投入，养成良好的习惯。  
今天补充下，Seata TCC模式实战。

--------------------

# 一、TCC设计原则 #

从 TCC 模型的框架可以发现，TCC 模型的核心在于 TCC 接口的设计。用户在接入 TCC 时，大部分工作都集中在如何实现 TCC 服务上。

设计一套 TCC 接口最重要的是什么？主要有两点，  
**第一点，需要将操作分成两阶段完成**。TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖 RM 对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。

TCC 模型认为对于业务系统中一个特定的业务逻辑 ，其对外提供服务时，必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业务服务的取消操作。而当主业务服务认为全局事务应该提交时，它会放弃之前临时性操作的取消权，这对应从业务服务的确认操作。每一个初步操作，最终都会被确认或取消。

因此，针对一个具体的业务服务，**TCC 分布式事务模型需要业务系统提供三段业务逻辑**：

> 1、初步操作 Try：完成所有业务检查，预留必须的业务资源。  
> 2、确认操作 Confirm：真正执行的业务逻辑，不做任何业务检查，只使用Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功另外，Confirm操作需满足幂等性，保证一笔分布式事务能且只能成功一次。  
> 注意：这里说的confirm方法必须能成功是指满足业务执行的条件，比如有足够的预留资源扣减，方法本身不能说保证一定成功。因为所有的网络操作都具有不确定性。  
> 3、取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel操作也需要满足幂等性。

**第二点，就是要根据自身的业务模型控制并发，这个对应 ACID 中的隔离性**。后面会详细讲到。

# 二、TCC执行逻辑图 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70]

# 三、TCC模式和AT模式对比 #

根据两阶段行为模式的不同，我们将分支事务划分为 Automatic (Branch) Transaction Mode 和 TCC (Branch) Transaction Mode.  
AT 模式（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：  
一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。  
二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。  
二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，**不依赖于底层数据资源的事务支持**：  
一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。  
二阶段 commit 行为：调用 自定义 的 commit 逻辑。  
二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。  
所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中。

**综合比较：**  
1、AT需要支持本地 ACID 事务的关系型数据库，TCC不依赖底层数据资源对事务的支持。  
2、AT模式使用了全局锁和本地锁，能保证强一致性。TCC只能保证最终一致性。  
3、AT模式由于大量使用了锁，吞吐量较低。  
4、实现复杂度上，AT模式只需要简单的添加全局事务注解，基本可以实现零侵入，而TCC模式需要自己实现prepare、commit、rollback方法，并考虑空回滚、幂等、悬挂等问题，实现成本较高。

# 四、TCC三大异常说明 #

最常见的主要是这三种异常，分别是空回滚、幂等、悬挂。

## 1、空回滚 ##

首先是空回滚。什么是空回滚？空回滚就是对于一个分布式事务，在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

什么样的情形会造成空回滚呢？可以看图中的第 2 步，前面讲过，注册分支事务是在调用 RPC 时，Seata 框架的切面会拦截到该次调用请求，先向 TC 注册一个分支事务，然后才去执行 RPC 调用逻辑。如果 RPC 调用逻辑有问题，比如调用方机器宕机、网络异常，都会造成 RPC 调用失败，即未执行 Try 方法。但是分布式事务已经开启了，需要推进到终态，因此，TC 会回调参与者二阶段 Cancel 接口，从而形成空回滚。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 1]  
那会不会有空提交呢？理论上来说不会的，如果调用方宕机，那分布式事务默认是回滚的。如果是网络异常，那 RPC 调用失败，发起方应该通知 TC 回滚分布式事务，这里可以看出为什么是理论上的，就是说发起方可以在 RPC 调用失败的情况下依然通知 TC 提交，这时就会发生空提交，这种情况要么是编码问题，要么开发同学明确知道需要这样做。

那怎么解决空回滚呢？前面提到，Cancel 要识别出空回滚，直接返回成功。那关键就是要识别出这个空回滚。\*\*思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；\*\*如果没执行，那就是空回滚。因此，需要一张额外的事务控制表，其中有分布式事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。

## 2、幂等 ##

接下来是幂等。幂等就是对于同一个分布式事务的同一个分支事务，重复去调用该分支事务的第二阶段接口，因此，要求 TCC 的二阶段 Confirm 和 Cancel 接口保证幂等，不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致资损等严重问题。

什么样的情形会造成重复提交或回滚？从图中可以看到，提交或回滚是一次 TC 到参与者的网络调用。因此，网络故障、参与者宕机等都有可能造成参与者 TCC 资源实际执行了二阶段防范，但是 TC 没有收到返回结果的情况，这时，TC 就会重复调用，直至调用成功，整个分布式事务结束。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 2]  
怎么解决重复执行的幂等问题呢？一个简单的思路就是记录每个分支事务的执行状态。在执行前状态，如果已执行，那就不再执行；否则，正常执行。前面在讲空回滚的时候，已经有一张事务控制表了，事务控制表的每条记录关联一个分支事务，那我们完全可以在这张事务控制表上加一个状态字段，用来记录每个分支事务的执行状态。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 3]  
如图所示，该状态字段有三个值，分别是初始化、已提交、已回滚。Try 方法插入时，是初始化状态。二阶段 Confirm 和 Cancel 方法执行后修改为已提交或已回滚状态。当重复调用二阶段接口时，先获取该事务控制表对应记录，检查状态，如果已执行，则直接返回成功；否则正常执行。

## 3、悬挂 ##

最后是防悬挂。悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。因为允许空回滚的原因，Cancel 接口认为 Try 接口没执行，空回滚直接返回成功，对于 Seata 框架来说，认为分布式事务的二阶段接口已经执行成功，整个分布式事务就结束了。但是这之后 Try 方法才真正开始执行，预留业务资源，前面提到事务并发控制的业务加锁，对于一个 Try 方法预留的业务资源，只有该分布式事务才能使用，然而 Seata 框架认为该分布式事务已经结束，也就是说，当出现这种情况时，**该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。**

**简单来说，悬挂就是 Cancel 接口比 Try 接口先执行，Cancel 接口进行了空回滚，Try 接口才执行进行资源预留，而预留的资源又没有对应的Cancel 接口去进行消费，所以导致这部分预留资源没法处理。**

什么样的情况会造成悬挂呢？按照前面所讲，在 RPC 调用时，先注册分支事务，再执行 RPC 调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，发起方就会通知 TC 回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者，真正执行，从而造成悬挂。

怎么实现才能做到防悬挂呢？根据悬挂出现的条件先来分析下，悬挂是指二阶段 Cancel 执行完后，一阶段才执行。也就是说，为了避免悬挂，如果二阶段执行完成，那一阶段就不能再继续执行。因此，当一阶段执行时，需要先检查二阶段是否已经执行完成，如果已经执行，则一阶段不再执行；否则可以正常执行。那怎么检查二阶段是否已经执行呢？大家是否想到了刚才解决空回滚和幂等时用到的事务控制表，可以在二阶段执行时插入一条事务控制记录，状态为已回滚，这样当一阶段执行时，先读取该记录，如果记录存在，就认为二阶段已经执行；否则二阶段没执行。

# 五、案例实战 #

## 1、业务说明 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 4]  
**业务说明：**  
1、用户向Order服务发起下订单的请求；  
2、Order服务收到请求后，开始创建订单；  
3、Order服务向Storage库存服务发起请求，减去商品库存；  
4、Order服务向Account账户服务发起请求，减少账户余额；  
5、全部执行成功，则成功创建订单。

## 2、项目结构 ##

![在这里插入图片描述][20210426163023860.png]  
说明：  
1、account工程是账户服务，用户管理账户余额。  
2、db-init工程用户初始化项目表结构和数据。  
3、easy-id-generator工程用来生成全局唯一的订单id，用来控制创建订单方法的幂等性。  
4、eureka-server工程是采用eureka作为注册中心。  
5、order工程是订单服务，用来新建订单。  
6、order-parent是整合微服务项目的公共父依赖，类似spring-boot-starter-parent。  
7、storage工程是库存服务，用来管理商品库存。

## 3、maven依赖 ##

spring cloud和spring boot的版本对应关系：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 5]

spring cloud、spring boot、spring cloud Alibaba（spring-cloud-starter-alibaba-seata）三者的版本对应关系。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 6]  
和seata之间的版本对应关系：[官方地址][Link 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 7]  
**注意：**  
spring-cloud-starter-alibaba-seata归属与Spring Cloud Alibaba体系，两者版本保持一致。

版本说明：  
spring-cloud-starter-alibaba-seata 2.1.0内嵌seata-all 0.7.1，2.1.1内嵌seata-all 0.9.0，2.2.0内嵌seata-spring-boot-starter 1.0.0, 2.2.1内嵌seata-spring-boot-starter 1.1.0。

其中seata-spring-boot-starter的核心是包含一个对应的seata-all依赖，两者的版本保持一致。

引用的时候主要需要保证spring-cloud-starter-alibaba-seata和当前项目的spring cloud的版本保持一致，  
seata的版本可以通过exclusion排除默认依赖后，升级成较新的依赖。**这样就做到了spring cloud版本和seate版本的解耦。**

**spring-cloud-starter-alibaba-seata推荐依赖配置方式**

<dependency>
                <groupId>io.seata</groupId>
                <artifactId>seata-spring-boot-starter</artifactId>
                <version>最新版</version>
            </dependency>
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
                <version>2.2.1.RELEASE</version>
                <exclusions>
                    <exclusion>
                        <groupId>io.seata</groupId>
                        <artifactId>seata-spring-boot-starter</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>

**说明：**  
spring-cloud-starter-alibaba-seata的版本选择与项目依赖的spring cloud相匹配的版本。通过exclusion排除默认依赖的seata，然后引入自己想要的seata版本，实现spring cloud的版本和seata的依赖版本解耦。  
注意spring-cloud-starter-alibaba-seata 2.1.0内嵌seata-all 0.7.1，2.1.1内嵌seata-all 0.9.0，2.2.0内嵌seata-spring-boot-starter 1.0.0, 2.2.1内嵌seata-spring-boot-starter 1.1.0。

所以如果是spring-cloud-starter-alibaba-seata 2.1.x的版本，依赖的是seata-all ，所以推荐如下配置：

<dependency>
              <groupId>com.alibaba.cloud</groupId>
              <artifactId>spring-cloud-alibaba-seata</artifactId>
              <version>${ spring-cloud-alibaba-seata.version}</version>
              <exclusions>
                <exclusion>
                  <artifactId>seata-all</artifactId>
                  <groupId>io.seata</groupId>
                </exclusion>
              </exclusions>
            </dependency>
            
            <dependency>
              <groupId>io.seata</groupId>
              <artifactId>seata-all</artifactId>
              <version>${ seata.version}</version>
            </dependency>

**order-parent父级项目的核心依赖：**

<parent>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-parent</artifactId>
            <version>2.2.6.RELEASE</version>
          <relativePath/> 
        </parent>
        <groupId>cn.tedu</groupId>
        <artifactId>order-parent</artifactId>
        <version>1.0-SNAPSHOT</version>
        <packaging>pom</packaging>
        <name>order-parent</name>
    
    
        <properties>
            <mybatis-plus.version>3.3.2</mybatis-plus.version>
            <druid-spring-boot-starter.version>1.1.23</druid-spring-boot-starter.version>
            <seata.version>1.3.0</seata.version>
            <spring-cloud-alibaba-seata.version>2.0.0.RELEASE</spring-cloud-alibaba-seata.version>
            <spring-cloud.version>Hoxton.SR6</spring-cloud.version>
            <skipTests>true</skipTests>
        </properties>
    
         <dependencies>
             
            <dependency>
              <groupId>com.alibaba.cloud</groupId>
              <artifactId>spring-cloud-alibaba-seata</artifactId>
              <version>${ spring-cloud-alibaba-seata.version}</version>
              <exclusions>
                <exclusion>
                  <artifactId>seata-all</artifactId>
                  <groupId>io.seata</groupId>
                </exclusion>
              </exclusions>
            </dependency>
            <dependency>
              <groupId>io.seata</groupId>
              <artifactId>seata-all</artifactId>
              <version>${ seata.version}</version>
            </dependency>
               ……
      </dependencies>
    
        <dependencyManagement>
            <dependencies>
                <dependency>
                    <groupId>org.springframework.cloud</groupId>
                    <artifactId>spring-cloud-dependencies</artifactId>
                    <version>${ spring-cloud.version}</version>
                    <type>pom</type>
                    <scope>import</scope>
                </dependency>
            </dependencies>
        </dependencyManagement>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 8]

## 4、属性配置 ##

### （1）、conf文件方式 ###

针对spring-cloud-starter-alibaba-seata 2.1.x的版本，由于依赖的是seata-all，没有整合更丰富的seata配置，所以一般采用的是属性文件 + conf配置文件的方式进行配置：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 9]  
**属性文件配置如下：**

spring.cloud.alibaba.seata.tx-service-group=order_tx_group

说明：  
通过设置spring.cloud.alibaba.seata.tx-service-group属性设置事务服务的分组名称。

file.conf和registry.conf文件都可以在seata按照文件下找到。其中file.conf用来配置网络、服务端server以及客户端的相关属性。  
registry.conf用来配置seata server注册的注册中心，以及属性文件保存的配置中心。

**file.conf核心配置：**

service { 
      #transaction service group mapping
      # order_tx_group 与 yml 中的 “tx-service-group: order_tx_group” 配置一致
      # “seata-server” 与 TC 服务器的注册名一致
      # order_tx_group名称需要和属性文件中配置的spring.cloud.alibaba.seata.tx-service-group的值相匹配
      #  vgroupMapping属性是为了配置
      vgroupMapping.order_tx_group = "seata-server"
      #only support when registry.type=file, please don't set multiple addresses
      # seata-server的名称需要和上面的vgroupMapping.order_tx_group的值相匹配。
      seata-server.grouplist = "127.0.0.1:8091"
      #degrade, current not support
      enableDegrade = false
      #disable seata
      disableGlobalTransaction = false
    }

**注意：**  
1、vgroupMapping.order\_tx\_group中的order\_tx\_group需要和属性文件中配置的spring.cloud.alibaba.seata.tx-service-group的值相匹配  
2、 seata-server.grouplist中的seata-server.需要和vgroupMapping.order\_tx\_group的值匹配  
核心的目的就是指定seata-server的服务分组名称，以及seata-server服务对应的服务器ip地址。

**registry.conf核心配置：**  
这里由于测试，且我的seata-server服务采用的默认file方式部署的，所以这里的registry.conf也都是采用的默认的，没有做相关修改。实际使用中可以根据情况和需求，修改成自己对应的配置中心和注册中心。

registry { 
      # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
      type = "file"
    
      file { 
        name = "file.conf"
      }
    }
    
    config { 
      # file、nacos 、apollo、zk、consul、etcd3、springCloudConfig
      type = "file"
      file { 
        name = "file.conf"
      }
    }

### （2）、属性文件配置方式 ###

针对spring-cloud-starter-alibaba-seata 2.2.x以后的版本，由于依赖的是seata-spring-boot-starter，整合了更丰富的seata配置，所以可以省去conf文件，将seata相关数据都在属性文件中进行配置。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 10]  
application.yml属性配置：

seata:
      enabled: true
      tx-service-group: order_tx_group
      service:
        vgroup-mapping:
         order_tx_group: seata-server
        grouplist:
          seata-server: 127.0.0.1:8091

注意：  
1、注意属性文件配置中map类型属性配置的对应关系。  
2、注意几个属性之间的关联关系。  
![在这里插入图片描述][20210428202536706.png]

### （3）、补充说明 ###

**事务分组说明**

1.  事务分组是什么？  
    事务分组是seata的资源逻辑，类似于服务实例。在file.conf中的my\_test\_tx\_group就是一个事务分组。
2.  通过事务分组如何找到后端集群？  
    首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的txServiceGroup参数），程序会通过用户配置的配置中心去寻找service.vgroup\_mapping.事务分组配置项，取得配置项的值就是TC集群的名称。拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同。拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的TC服务列表。
3.  为什么这么设计，不直接取服务名？  
    这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，当发生故障时可以快速failover。

**关于grouplist问题说明下**

1.  什么时候会用到file.conf中的default.grouplist？  
    当registry.type=file时会用到，其他时候不读。
2.  default.grouplist的值列表是否可以配置多个？  
    可以配置多个，配置多个意味着集群，但当store.mode=file时，会报错。原因是在file存储模式下未提供本地文件的同步，所以需要使用store.mode=db，通过db来共享TC集群间数据
3.  是否推荐使用default.grouplist？  
    不推荐，如问题1，当registry.type=file时会用到，也就是说这里用的不是真正的注册中心，不具体服务的健康检查机制当tc不可用时无法自动剔除列表，推荐使用nacos 、eureka、redis、zk、consul、etcd3、sofa。registry.type=file或config.type=file 设计的初衷是让用户再不依赖第三方注册中心或配置中心的前提下，通过直连的方式，快速验证seata服务。

## 5、TCC事务代码 ##

### （1）、创建订单核心代码 ###

@GlobalTransactional
        @Override
        public void create(Order order) { 
            // 从全局唯一id发号器获得id
            Long orderId = easyIdGeneratorClient.nextId("order_business");
            order.setId(orderId);
            String xid = RootContext.getXID();
            log.info("New Transaction Begins: " + xid);
            // orderMapper.create(order);
    
            // 这里修改成调用 TCC 第一节端方法
            orderTccAction.prepareCreateOrder(
                    null,
                    order.getId(),
                    order.getUserId(),
                    order.getProductId(),
                    order.getCount(),
                    order.getMoney());
    
            // 修改库存
            storageClient.decrease(order.getProductId(), order.getCount());
    
            // 修改账户余额
            accountClient.decrease(order.getUserId(), order.getMoney());
    
        }

**说明：**  
1、通过添加 @GlobalTransactional注解，开启seata全局分布式事务。  
2、通过生成全局的订单id控制事务的幂等性。

### （2）、OrderTccAction ###

@LocalTCC
    public interface OrderTccAction { 
        /* 第一阶段的方法 通过注解指定第二阶段的两个方法名 BusinessActionContext 上下文对象，用来在两个阶段之间传递数据 @BusinessActionContextParameter 注解的参数数据会被存入 BusinessActionContext */
        @TwoPhaseBusinessAction(name = "orderTccAction", commitMethod = "commit", rollbackMethod = "rollback")
        boolean prepareCreateOrder(BusinessActionContext businessActionContext,
                          @BusinessActionContextParameter(paramName = "orderId") Long orderId,
                          @BusinessActionContextParameter(paramName = "userId") Long userId,
                          @BusinessActionContextParameter(paramName = "productId") Long productId,
                          @BusinessActionContextParameter(paramName = "count") Integer count,
                          @BusinessActionContextParameter(paramName = "money") BigDecimal money);
    
        // 第二阶段 - 提交
        boolean commit(BusinessActionContext businessActionContext);
    
        // 第二阶段 - 回滚
        boolean rollback(BusinessActionContext businessActionContext);
    
    }

说明：  
1、通过在接口上添加@LocalTCC注解，声明本地TCC事务控制接口  
2、通过@TwoPhaseBusinessAction注解，声明Try、Confirm、Cancel三个阶段对应的具体方法。

### （3）、OrderTccActionImpl ###

@Component
    @Slf4j
    public class OrderTccActionImpl implements OrderTccAction { 
        @Autowired
        private OrderMapper orderMapper;
    
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean prepareCreateOrder(BusinessActionContext businessActionContext, Long orderId, Long userId, Long productId, Integer count, BigDecimal money) { 
            log.info("创建 order 第一阶段，预留资源 - "+businessActionContext.getXid());
    
            //因为orderId是唯一的，不能重复执行，满足幂等性， 创建状态为0（创建中）的订单
            Order order = new Order(orderId, userId, productId, count, money, 0);
            orderMapper.create(order);
    
            //模拟异常
            /* if (Math.random() < 0.9999) { throw new RuntimeException("模拟try阶段出现 异常"); }*/
            //事务成功，保存一个标识，供第二阶段进行判断
            ResultHolder.setResult(getClass(), businessActionContext.getXid(), "p");
            return true;
        }
    
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean commit(BusinessActionContext businessActionContext) { 
            log.info("创建 order 第二阶段提交，修改订单状态1 - "+businessActionContext.getXid());
    
            // 防止幂等性，如果commit阶段重复执行则直接返回
            if (ResultHolder.getResult(getClass(), businessActionContext.getXid()) == null) { 
                return true;
            }
    
            //Long orderId = (Long) businessActionContext.getActionContext("orderId");
            long orderId = Long.parseLong(businessActionContext.getActionContext("orderId").toString());
            //确认提交，将订单状态修改为1（创建完成）
            orderMapper.updateStatus(orderId, 1);
    
            //提交成功是删除标识
            ResultHolder.removeResult(getClass(), businessActionContext.getXid());
            return true;
        }
    
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean rollback(BusinessActionContext businessActionContext) { 
            log.info("创建 order 第二阶段回滚，删除订单 - "+businessActionContext.getXid());
    
            //第一阶段没有完成的情况下，不必执行回滚（空回滚处理）
            //因为第一阶段有本地事务，事务失败时已经进行了回滚。
            //如果这里第一阶段成功，而其他全局事务参与者失败，这里会执行回滚
            //幂等性控制：如果重复执行回滚则直接返回
            if (ResultHolder.getResult(getClass(), businessActionContext.getXid()) == null) { 
                return true;
            }
    
            //创建识别，执行Cancel操作，删除临时订单
            //Long orderId = (Long) businessActionContext.getActionContext("orderId");
            long orderId = Long.parseLong(businessActionContext.getActionContext("orderId").toString());
            orderMapper.deleteById(orderId);
    
            //回滚结束时，删除标识
            ResultHolder.removeResult(getClass(), businessActionContext.getXid());
            return true;
        }
    }

**说明：**  
注意TCC具体的方法实现中，对幂等、空回滚、悬挂等问题的解决。  
核心逻辑解说：

1.  prepareCreateOrder方法对应try阶段，会根据唯一订单号创建临时状态订单，并在当前类下注入事务id
2.  commit对应confirm阶段，首先查看当前类是否和事务ID（businessActionContext.getXid()）有关联，没有关联就直接返回true，不进行真实的提交逻辑。如果关联了事务id，则修改订单状态为已完成，并移除关联的事务ID。
3.  rollback方法对应Cancel阶段，也是首先判断当前类下是否与businessActionContext.getXid()相关联，没有关联就直接返回true防止出现空回滚。如果有关联，则执行回滚操作，根据订单id删除临时状态的订单记录。
4.  注意TCC的3个实现方法都添加了@Transactional注解开启了事务控制，保证本地分支事务的ACID特性。

### （4）、订单表说明 ###

CREATE TABLE `order` (
      `id` bigint(11) NOT NULL,
      `user_id` bigint(11) DEFAULT NULL COMMENT '用户id',
      `product_id` bigint(11) DEFAULT NULL COMMENT '产品id',
      `count` int(11) DEFAULT NULL COMMENT '数量',
      `money` decimal(11,0) DEFAULT NULL COMMENT '金额',
      `status` int(1) DEFAULT NULL COMMENT '订单状态：0：创建中；1：已完结',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

**说明：**  
在TCC模式下，由于需要资源预留，一般都会在事务参与的表中添加一个资源预留字段。  
在订单表中的呈现是新增了订单状态字段，记录创建中状态的订单。

### （5）、order服务项目结构 ###

![在这里插入图片描述][20210429105040481.png]  
**说明：**  
1、远程调用都采用feign调用，统一存放在feign目录下  
2、tcc相关的接口，统一放在tcc目录下  
3、由于order服务采用的是spring-cloud-starter-alibaba-seata 2.2.1.RELEASE版本，seata-spring-boot-starter为1.4.1版本，order中采用的是属性配置项设置的seata相关属性，省略了file.conf和registry.conf文件。

### （6）、account服务核心代码 ###

@Component
    @Slf4j
    public class AccountTccActionImpl implements AccountTccAction { 
        @Autowired
        private AccountMapper accountMapper;
    
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean prepareDecreaseAccount(BusinessActionContext businessActionContext, Long userId, BigDecimal money) { 
            log.info("减少账户金额，第一阶段锁定金额，userId="+userId+"， money="+money);
    
            //剩余可用金额
            Account account = accountMapper.selectById(userId);
            if (account.getResidue().compareTo(money) < 0) { 
                throw new RuntimeException("账户金额不足");
            }
    
            /* * 冻结可用金额 余额-money 冻结+money */
            accountMapper.updateFrozen(userId, account.getResidue().subtract(money), account.getFrozen().add(money));
    
            //模拟异常
            if (Math.random() < 0.3) { 
                throw new RuntimeException("模拟异常");
            }
    
            //保存标识
            ResultHolder.setResult(getClass(), businessActionContext.getXid(), "p");
            return true;
        }
    
        /** * Confirm 方法一定要在 Try 方法之后执行。因此，Confirm 方法只需要关注重复提交的问题。 * @param businessActionContext * @return */
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean commit(BusinessActionContext businessActionContext) { 
            long userId = Long.parseLong(businessActionContext.getActionContext("userId").toString());
            BigDecimal money =  new BigDecimal(businessActionContext.getActionContext("money").toString());
            log.info("减少账户金额，第二阶段，提交，userId="+userId+"， money="+money);
    
            //防止重复提交，确认try方法已经执行
            if (ResultHolder.getResult(getClass(), businessActionContext.getXid()) == null) { 
                return true;
            }
    
            accountMapper.updateFrozenToUsed(userId, money);
    
            //删除标识
            ResultHolder.removeResult(getClass(), businessActionContext.getXid());
            return true;
        }
    
        @Transactional(rollbackFor = Exception.class)
        @Override
        public boolean rollback(BusinessActionContext businessActionContext) { 
            long userId = Long.parseLong(businessActionContext.getActionContext("userId").toString());
            BigDecimal money =  new BigDecimal(businessActionContext.getActionContext("money").toString());
    
            //防止重复提交，确保try方法已经执行，防止空回滚
            if (ResultHolder.getResult(getClass(), businessActionContext.getXid()) == null) { 
                return true;
            }
    
            log.info("减少账户金额，第二阶段，回滚，userId="+userId+"， money="+money);
    
            accountMapper.updateFrozenToResidue(userId, money);
    
            //删除标识
            ResultHolder.removeResult(getClass(), businessActionContext.getXid());
            return true;
        }
    
    }

**说明：**  
账户金额扣减TCC逻辑的3个阶段说明

1.  prepareDecreaseAccount方法对应Try阶段，主要是执行资源预留，将要扣减的金额先保留到冻结金额中。
2.  commit方法对应Confirm阶段，事务提交过程，主要负责将冻结的金额真正扣除。
3.  rollback方法对应Cancel阶段，事务回滚，主要负责将冻结的金额解冻返回到账户的余额中。

### （7）、account表 ###

CREATE TABLE `account` (
      `id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT 'id',
      `user_id` bigint(11) DEFAULT NULL COMMENT '用户id',
      `total` decimal(10,0) DEFAULT NULL COMMENT '总额度',
      `used` decimal(10,0) DEFAULT NULL COMMENT '已用余额',
      `residue` decimal(10,0) DEFAULT '0' COMMENT '剩余可用额度',
      `frozen` decimal(10,0) DEFAULT '0' COMMENT 'TCC事务锁定的金额',
      PRIMARY KEY (`id`),
      UNIQUE KEY `user_id` (`user_id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

**说明：**  
主要是新增了frozen字段，用来保存暂时冻结的金额。

## 6、测试 ##

1.  先启动db-init服务，初始化数据库
2.  再启动eureka-server服务，作为注册中心
3.  然后启动其他服务。  
    ![在这里插入图片描述][20210429110318176.png]  
    发起创建订单请求：[http://localhost:8083/create?userId=1&productId=1&count=10&money=100][http_localhost_8083_create_userId_1_productId_1_count_10_money_100]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 11]  
    ![在这里插入图片描述][20210429110441644.png]、

## 7、异常模拟 ##

分别在TCC的各个阶段添加模拟的异常，看程序的执行情况。

//模拟try阶段异常
        if (Math.random() < 0.9999) { 
            throw new RuntimeException("模拟try阶段出现异常");
        }
    
        if (Math.random() < 0.9999) { 
            throw new RuntimeException("模拟commit阶段异常");
        }
     
        if (Math.random() < 0.9999) { 
            throw new RuntimeException("模拟cancel阶段异常");
        }

**说明：**

1.  事务的执行顺序是：创建订单——》修改库存——》减账户余额，  
    创建订单的try阶段出现异常，会触发创建订单TCC操作中的Cancel操作进行空回滚；  
    修改库存的try阶段出现异常，会触发创建订单TCC操作中的Cancel操作以及修改库存TCC操作中的Cancel操作进行空回滚；  
    减账户余额的try阶段出现异常，会触发创建订单TCC操作中的Cancel操作以及扣减库存的TCC操作中的Cancel操作，减账户余额的TCC操作中的Cancel操作进行空回滚。
2.  Confirm操作出现异常后，会不停的重试，直到执行成功。
3.  Cancel操作出现异常后，也会不停重试，直到执行成功。  
    （针对这里Confirm、Cancel的操作建议加入重试次数，失败一定操作后停止，记录相关记录，后面人工介入处理）。

## 8、seata tcc模式实战源码 ##

[GitHub地址][GitHub]

# 总结 #

1、理解TCC模式的底层逻辑：核心是将一个完整的事务分成了2个阶段，一阶段是所有事务参与者RM都注册到TC事务协调器，并发起分支事务请求进行资源预留，然后主动向TC汇报执行结果。二阶段TC事务协调器会根据收到的所有RM一阶段分支事务的执行结果来判断让RM继续执行提交操作还是回滚操作。  
2、知道TCC模式和AT模式差别以及相互之间的优势。  
3、实现TCC需要自己实现prepare、commit、rollback方法，并考虑空回滚、幂等、悬挂等问题。  
4、知道怎么使用Seata框架实现 TCC事务。  
5、需要在相关表中添加字段，用来保存预留资源。

很多人对分布式事务都心存畏惧，一是工作中接触的机会少，二是网上可以参考的实际可用的案例真的太少，大多数小伙伴都只是背了下各种分布式事务的相关实现方案的理论，而没有实际实现经验。

推荐大家都自己动手实战一番，做到心中有数，遇事不慌，而不是空谈理论。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70]: /images/20221022/a2aa40ef5e0445159fa5fedff395b6e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 1]: /images/20221022/48840c8ffdf44624bb03742a1fe5fa46.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 2]: /images/20221022/5c736964e941432c9bb3c8004244fd6b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 3]: /images/20221022/ec58316c3b604885850ed2e03f3b4073.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 4]: /images/20221022/7a9dae3923644908b5ed2ef8c982c4b4.png
[20210426163023860.png]: /images/20221022/a175ec2e0ebf458eb81d2595bb802df4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 5]: /images/20221022/c860ae4d751a492eaec06fd5dafe3d45.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 6]: /images/20221022/7e3d60b12ad8454b91f1dff5e895112a.png
[Link 1]: https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 7]: /images/20221022/6bd1886875244ea3ac01976d1fdc4ff9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 8]: /images/20221022/b4a3b74b1b964f46b1bbd3a17344c55d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 9]: /images/20221022/91c4eb2c10ef4033b66c5136ff44a7ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 10]: /images/20221022/cda2b086e9794a02b9c0d1799840e276.png
[20210428202536706.png]: /images/20221022/b57a4372828e4e70bf75767f84f8f32e.png
[20210429105040481.png]: /images/20221022/c3591a353ab749ccbe903283c38caa3b.png
[20210429110318176.png]: /images/20221022/17479bd913764d78a44d612838580a76.png
[http_localhost_8083_create_userId_1_productId_1_count_10_money_100]: http://localhost:8083/create?userId=1&productId=1&count=10&money=100
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3cxMDE0MDc0Nzk0_size_16_color_FFFFFF_t_70 11]: /images/20221022/b8be18d625bd4eadae99e8fafc18f439.png
[20210429110441644.png]: /images/20221022/4f6314bcf18c4f28a6f82fba56ef5c6b.png
[GitHub]: https://github.com/StarlightWANLI/seata-tcc.git