SpringCloud
SpringCloud

SpringCloud-分布式事务Seate-TCC

1、基本流程

AT就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。

那么对应到 TCC 模式里，也是一样的，Seata 框架把每组 TCC 接口当做一个 Resource，称为 TCC Resource。这套 TCC 接口可以是 RPC，也以是服务内 JVM 调用。在业务启动时，Seata 框架会自动扫描识别到 TCC 接口的调用方和发布方。如果是 RPC 的话，就是 sofa:reference、sofa:service、dubbo:reference、dubbo:service 等。

扫描到 TCC 接口的调用方和发布方之后，如果是发布方，会在业务启动时向 TC 注册 TCC Resource，与 DataSource Resource 一样，每个资源也会带有一个资源 ID。

如果是调用方，Seata 框架会给调用方加上切面，与 AT 模式一样，在运行时，该切面会拦截所有对 TCC 接口的调用。每调用一次 Try 接口，切面会先向 TC 注册一个分支事务，然后才去执行原来的 RPC 调用。当请求链路调用完成后，TC 通过分支事务的资源 ID 回调到正确的参与者去执行对应 TCC 资源的 Confirm 或 Cancel 方法。

原理图如下：

可以看到只有Try接口是业务自己调用的，之后的commit和rollback都是TC调用。

2、基本使用

下面以转账为例演示TCC事务模式的使用方法，使用dubbo-spring-boot框架进行开发：

创建表：

1
2
3
4
5
6
7
8
create table t_account
(
    uid     bigint auto_increment primary key,
    balance double null,
    frozen  double null
);
insert into t_accont(uid,balance) values(1,10000);
insert into t_accont(uid,balance) values(2,20000);

1、首先定义TCC资源

转账业务拆分成扣款+打款两个action，所以定义两个接口DeductTccAction和AddTccAction(省略代码)

1
2
3
4
5
6
7
8
9
@LocalTCC 
public interface DeductTccAction {
    @TwoPhaseBusinessAction(name = "DeductTccAction")
    boolean prepare(BusinessActionContext actionContext,
                    @BusinessActionContextParameter(paramName = "uid") int uid,
                    @BusinessActionContextParameter(paramName = "amount")double amount);
    boolean commit(BusinessActionContext actionContext);
    boolean rollback(BusinessActionContext actionContext);
}

  • @LocalTCC标记这是一个TCC资源，缺少该注解事务会以AT模式运行，不会调用到commit和rollback方法

  • @TwoPhaseBusinessAction注解标记这是个TCC接口，同时指定commitMethod，rollbackMethod的名称

  • @BusinessActionContext是TCC事务中的上下文对象

  • @BusinessActionContextParameter注解标记的参数会在上下文中传播，即能通过BusinessActionContext对象在commit方法及rollback方法中取到该参数值

2、开发TCC接口的实现

使用dubbo框架实现

扣款方：

  • prepare – 判断资金是否足够amount-frozen>0，冻结资金frozen+amount

  • commit – balance-amount，并将frozen-amount

  • rollback – frozen-amount

收款方：

  • prepare – 空

  • commit – balance+amount

  • rollback – 空

源码请见：https://github.com/zzkenyon/seate-tcc

另一个案例：https://www.cnblogs.com/liqbk/p/13643790.html

3、遇到的问题

问题一：报错Could not initialize class io.seata.rm.datasource.undo.UndoLogParserFactory$SingletonHolder

https://github.com/seata/seata/issues/1692

添加依赖

1
2
3
4
5
6
7
  <!-- undo序列化方式 选择了哪个就要依赖哪个jar包-->
        <!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind -->
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.11.0</version>
</dependency>

添加依赖后应用启动失败，提示jar包版本冲突，而且是seata-spring-boot-starter中的4点几版本的spring-xxx包，然后排除掉这些依赖，启动成功

问题二：在TCC资源接口上没有添加@LocalTCC注解，运行之后事务是以AT模式生效的，标志就是只执行了TCC的第一阶段，就在AT中commit了，没有执行我写的commit接口。

3、TCC 异常控制

3.1 空回滚

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

什么样的情形会造成空回滚呢？可以看图中的第 2 步，前面讲过，注册分支事务是在调用 RPC 时，Seata 框架的切面会拦截到该次调用请求，先向 TC 注册一个分支事务，然后才去执行 RPC 调用逻辑。如果 RPC 调用逻辑有问题，比如调用方机器宕机、网络异常，都会造成 RPC 调用失败，即未执行 Try 方法。但是分布式事务已经开启了，需要推进到终态，因此，TC 会回调参与者二阶段 Cancel 接口，从而形成空回滚。

那会不会有空提交呢？理论上来说不会的，如果调用方宕机，那分布式事务默认是回滚的。如果是网络异常，那 RPC 调用失败，发起方应该通知 TC 回滚分布式事务，这里可以看出为什么是理论上的，就是说发起方可以在 RPC 调用失败的情况下依然通知 TC 提交，这时就会发生空提交，这种情况要么是编码问题，要么开发同学明确知道需要这样做。

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

3.2 幂等

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

什么样的情形会造成重复提交或回滚？从图中可以看到，提交或回滚是一次 TC 到参与者的网络调用。因此，网络故障、参与者宕机等都有可能造成参与者 TCC 资源实际执行了二阶段防范，但是 TC 没有收到返回结果的情况，这时，TC 就会重复调用，直至调用成功，整个分布式事务结束。

怎么解决重复执行的幂等问题呢？一个简单的思路就是记录每个分支事务的执行状态。在执行前状态，如果已执行，那就不再执行；否则，正常执行。前面在讲空回滚的时候，已经有一张事务控制表了，事务控制表的每条记录关联一个分支事务，那我们完全可以在这张事务控制表上加一个状态字段，用来记录每个分支事务的执行状态。

1
2
3
4
5
6
7
8
9
10
11
create table 'account_transation'(
  'tx_id' varchar(100) NOT NULL COMMENT '事务Txid',
  'action_id' varchar(100) NOT NULL COMMENT '分支事务id',
  'gmt_create' datetime NOT NULL NOT NULL COMMENT '创建时间',
  'gmt_modified' datetime NOT NULL NOT NULL COMMENT '修改时间',
	'user_id' varchar(100) NOT NULL NOT NULL COMMENT '账户UID',
  'amount' varchar(100) NOT NULL NOT NULL COMMENT '变动金额',
	'type' varchar(100) NOT NULL NOT NULL COMMENT '变动类型',
  'state' smallint(4) NOT NULL NOT NULL COMMENT '状态：1.初始化；2.已提交；3.已回滚',
  PRIMARY KEY('tx_id','action_id')
)ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='业务流水表'

该状态字段有三个值，分别是初始化、已提交、已回滚。Try 方法插入时，是初始化状态。二阶段 Confirm 和 Cancel 方法执行后修改为已提交或已回滚状态。当重复调用二阶段接口时，先获取该事务控制表对应记录，检查状态，如果已执行，则直接返回成功；否则正常执行。

3.3 悬挂

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

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

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

3.4 异常控制实现

在分析完空回滚、幂等、悬挂等异常 Case 的成因以及解决方案以后，下面我们就综合起来考虑，一个 TCC 接口如何完整的解决这三个问题。

首先是 Try 方法。结合前面讲到空回滚和悬挂异常，Try 方法主要需要考虑两个问题，一个是 Try 方法需要能够告诉二阶段接口，已经预留业务资源成功。第二个是需要检查第二阶段是否已经执行完成，如果已完成，则不再执行。因此，Try 方法的逻辑可以如图所示：

先插入事务控制表记录，如果插入成功，说明第二阶段还没有执行，可以继续执行第一阶段。如果插入失败，则说明第二阶段已经执行或正在执行，则抛出异常，终止即可。

接下来是 Confirm 方法。因为 Confirm 方法不允许空回滚，也就是说，Confirm 方法一定要在 Try 方法之后执行。因此，Confirm 方法只需要关注重复提交的问题。可以先锁定事务记录，如果事务记录为空，则说明是一个空提交，不允许，终止执行。如果事务记录不为空，则继续检查状态是否为初始化，如果是，则说明一阶段正确执行，那二阶段正常执行即可。如果状态是已提交，则认为是重复提交，直接返回成功即可；如果状态是已回滚，也是一个异常，一个已回滚的事务，不能重新提交，需要能够拦截到这种异常情况，并报警。

最后是 Cancel 方法。因为 Cancel 方法允许空回滚，并且要在先执行的情况下，让 Try 方法感知到 Cancel 已经执行，所以和 Confirm 方法略有不同。首先依然是锁定事务记录。如果事务记录为空，则认为 Try 方法还没执行，即是空回滚。空回滚的情况下，应该先插入一条事务记录，确保后续的 Try 方法不会再执行。如果插入成功，则说明 Try 方法还没有执行，空回滚继续执行。如果插入失败，则认为 Try 方法正再执行，等待 TC 的重试即可。如果一开始读取事务记录不为空，则说明 Try 方法已经执行完毕，再检查状态是否为初始化，如果是，则还没有执行过其他二阶段方法，正常执行 Cancel 逻辑。如果状态为已回滚，则说明这是重复调用，允许幂等，直接返回成功即可。如果状态为已提交，则同样是一个异常，一个已提交的事务，不能再次回滚。

4、TCC 性能优化

虽然 TCC 模型已经完备，但是随着业务的增长，对于 TCC 模型的挑战也越来越大，可能还需要一些特殊的优化，才能满足业务需求。下面我们将会给大家讲讲，蚂蚁金服内部在 TCC 模型上都做了哪些优化。

4.1 同库模式

第一个优化方案是改为同库模式。同库模式简单来说，就是分支事务记录与业务数据在相同的库中。什么意思呢？之前提到，在注册分支事务记录的时候，框架的调用方切面会先向 TC 注册一个分支事务记录，注册成功后，才会继续往下执行 RPC 调用。TC 在收到分支事务记录注册请求后，会往自己的数据库里插入一条分支事务记录，从而保证事务数据的持久化存储。那同库模式就是调用方切面不再向 TC 注册了，而是直接往业务的数据库里插入一条事务记录。

2.3.2 异步化

https://blog.csdn.net/huaishu/article/details/898809711