TCC 核心思想

      TCC 分布式事务最核心的思想就是在应用层将一个完整的事务操作分为三个阶段。在某种程度上讲，TCC 是一种资源，实现了 Try、Confirm、Cancel 三个操作接口。每个节点所关注的重点不同。

1、Try 阶段
      Try 阶段是准备执行业务的阶段，在这个阶段尝试执行业务，重点关注如下事项：

1. 完成所有的业务检查，确保数据的一致性；
2. 预留必要的业务资源，确保数据的隔离性。

      在下单扣减库存的业务场景中，如果使用了 TCC 分布式事务，则需要在 Try 阶段检查商品的库存数量是否大于或者等于下单提交的商品数量，如果商品的库存数量大于或者等于下单提交的商品数量，则标记扣减库存数量。此时的商品数量并没有真正扣减，只是做资源预留操作，并且会将订单信息保存到数据库，标记为待提交状态。如果商品的库存数量不足，则提示用户库存不足，并且删除提交的订单数据或者将订单标记为删除。
2、Confirm 阶段
      Confirm 阶段是确认执行业务的阶段，在这个阶段确认执行的业务。此时重点关注如下事项：

1. 真正地执行业务
2. 不做任何业务逻辑检查，直接将数据持久化到数据库
3. 直接使用 Try 阶段预留的业务资源

      在下单扣减库存的业务场景中，由于在 Try 阶段已经检查过商品的库存数量大于或者等于下单提交的商品数量，因此在 Confirm 阶段不会做二次检查，直接将订单的状态更新为“已提交”，并且真正执行扣减库存操作。在 Confirm 阶段是真正地执行业务操作，期间不会做任何业务检查，直接使用 Try 阶段预留的业务资源。

3、Cancel 阶段
      Cancel 阶段取消执行业务，重点关注如下事项：

1. 释放 Try 阶段预留的业务资源
2. 将数据库中的数据恢复到最初的状态

      在下单扣减库存的业务场景中，假设 Try 阶段检查的结果为商品的库存数量足够，在执行完订单提交业务后，执行扣减库存操作时发生异常，或者在执行 Confirm 阶段的业务时发生异常。此时，会执行 Cancel 阶段的操作回滚业务，使数据回到提交订单之前的状态。

TCC 核心流程

Try 阶段流程

      在电商支付订单的业务场景中，Try 阶段主要的业务流程如下图所示：

1. 订单服务将订单数据库中的订单状态更新为"支付中"；
2. 订单服务调用库存服务冻结部分库存，将冻结的库存数量也就是用户下单的数量单独写入商品库存表的冻结字段中，同时将商品库存数量减去冻结的商品数量；
3. 订单服务调用积分服务进行预增加积分的操作，在用户积分数据表中，将要增加的积分写入单独的预增加积分字段中，而不是直接增加用户的积分；
4. 订单服务调用仓储服务生成出库单时，将出库单的状态标记为"未知"，并不直接生成正常的出库单。

Confirm 阶段流程

      如果 Try 阶段的业务逻辑全部执行成功，则 TCC 分布式事务会执行 Confirm 阶段的业务逻辑。在实际场景中，Confirm 阶段的执行往往是由 TCC 分布式事务框架调用完成的。在订单服务中会将订单的状态由"支付中"更新"支付成功"。在库存服务中会真正地扣减库存，将写入冻结字段的库存数量减去当前下单的商品数量。在积分服务中会将当次支付产生的积分从预增加积分字段中扣除，并将对应的积分增加到用户积分账户中。在仓储服务中会将出库单状态由"未知"更新为"已创建"。

Cancel 阶段流程

      如果 Try 阶段的业务执行失败，或者某个服务出现异常等，TCC 分布式事务框架能够感知到这些异常信息，会自动执行 Cancel 阶段的流程，对整个 TCC 分布式事务进行回滚。在实际场景中，Cancel 阶段的执行往往是由 TCC 分布式事务框架调用完成的。
      在订单服务中，将订单的状态更新为"已取消"。在库存服务中，将当次下单提交的商品数量加回到库存字段中，并且在预扣减库存的字段中减去当次下单的商品数量。在积分服务中，在预增加积分字段中减去当前支付产生的积分数量。在仓储服务中，将出库单的状态标记为"已取消"。

TCC 关键技术

AOP 切面

      实现 TCC 分布式事务的第一个核心技术就是 AOP 切面。无论是 TCC 分布式事务的发起者，还是参与者，都需要经过 AOP 切面的处理。通过 AOP 切面拦截具体的业务逻辑，在AOP 切面中执行事务日志的记录、远程调用等逻辑。诸如 Hmily 框架中大量使用了 Spring 的 AOP 切面，处理分布式事务的问题。

反射技术

      实现 TCC 分布式事务的第二个核心技术就是反射技术。TCC 分布式事务中 Confirm 阶段的方法和 Cancel 阶段的方法是通过反射技术调用的。这也就是 Hmily 框架在 Try 阶段的方法上使用注解来指定 Confirm 方法和 Cancel 方法的原因。在 Try 阶段的方法上使用注解指定 Confirm 方法和 Cancel 方法，Hmily 框架会在执行完 Try 方法后，使用反射技术自动调用 Confirm 方法或者 Cancel 方法。

持久化技术

      实现 TCC 分布式事务的第三个核心技术就是持久化技术。在分布式事务的实现中，所有参与事务的服务都存在数据的持久化操作。在分布式环境中，由于网络的不稳定性，随时都有可能出现调用服务方法失败的情况，在 TCC 分布式事务中，需要保证数据的最终一致性。如果只有一部分的请求被正常处理，则另一部分服务的请求最终也需要被处理，对请求数据持久化是必不可少的。Hmily 框架不仅支持使用 Redis、Zookeeper、文件、缓存、ETCD、MongoDB 等进行持久化操作，还提供了 SPI 扩展接口，使具体业务能够根据实际需求实现自身的持久化技术。

序列化技术

      实现 TCC 分布式事务的第四个核心技术就是序列化技术。在分布式环境中，数据的持久化和在网络中的传输，都需要序列化技术的支持。Hmily 框架支持的序列化技术包括 JDK 自带的序列化技术、Hessian 序列化技术、Kyro 序列化技术、MsgPack 序列化技术和 ProtoBuf 序列化技术。另外，Hmily 框架还提供了 SPI 扩展接口，使具体的业务能够根据实际需求实现自身的序列化技术。

定时任务

      实现 TCC 分布式事务的第五个核心技术就是定时任务。在分布式环境中，由于网络的不稳定性，难免会出现方法调用失败的情况，此时需要利用定时任务来重试方法的调用操作。Hmily 框架实现了当方法调用失败时，使用定时任务进行重试的机制。

动态代理

      实现 TCC 分布式事务的第六个核心技术就是动态代理。分布式环境中存在很多远程调用框架，在分布式事物的实现过程中，需要通过动态代理的方式支持远程调用框架。例如，在 Hmily 框架中通过动态代理支持多种远程调用框架，这些远程调用框架包括 Dubbo、gRPC、Motan、Sofa-RPC、Spring Cloud、Tars等。

多配置源技术

      实现 TCC 分布式事务的第七个核心技术就是多配置源技术。在分布式环境中，为了便于管理各业务系统的配置，往往会集中存储各业务系统的配置，并通过相应的技术快速同步到各业务系统的本地缓存中。由于在真正的业务场景中，会存在不同的配置存储技术，因此实现分布式事务是，需要支持多配置源技术。例如，在 Hmily 框架中，就实现了多种配置源技术，这些配置源包括 Apollo、Consul、ETCD、Loader、Nacos、Zookeeper、本地存储等。另外，Hmily 框架还提供了 SPI 扩展接口，使具体的业务能够根据实际需求实现自身的配置源技术。

版权属于：带翅膀的猫

本文链接：https://www.chengpengper.cn/archives/233/

转载时须注明出处及本声明