阿里巴巴开源分布式框架Seata TCC模式深入分析

2019 年 3 月，蚂蚁金服加入分布式事务 Seata 的社区共建中，并贡献其 TCC 模式。本期是 SOFAChannel 第四期，主题：分布式事务 Seata TCC 模式深度解析，本文根据觉生的直播整理。
大家晚上好，我是 Seata Committer 觉生，来自蚂蚁金服数据中间件团队。今天的内容主要分为以下四个部分：
Seata TCC 模式的原理解析；
从 TCC 的业务模型与并发控制分享如何设计一个 TCC 接口，并且适配 TCC 模型；
如何控制异常；
性能优化，使得 TCC 模式能够满足更高的业务需求。

1 Seata 的 TCC 模式

1.1 服务化拆

下面我们就进入第一个主题，Seata 的 TCC 模式。蚂蚁金服早期是单系统架构，所有业务服务几乎都在少数几个系统中。随着业务的发展，业务越来越复杂，服务之间的耦合度也越来越高，故我们对系统进行了重构，服务按照功能进行解耦和垂直拆分。拆分之后所带来的问题就是一个业务活动原来只需要调用一个服务就能完成，现在需要调用多个服务才能完成，而网络、机器等不可靠，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融 IT 架构支撑业务转型升级的最大挑战之一。

从图中可以看到，从单系统到微服务转变，其实是一个资源横向扩展的过程，资源的横向扩展是指当单台机器达到资源性能瓶颈，无法满足业务增长需求时，就需要横向扩展资源，形成集群。通过横向扩展资源，提升非热点数据的并发性能，这对于大体量的互联网产品来说，是至关重要的。服务的拆分，也可以认为是资源的横向扩展，只不过方向不同而已。

资源横向扩展可能沿着两个方向发展，包括业务拆分和数据分片：

业务拆分。根据功能对数据进行分组，并将不同的微服务分布在多个不同的数据库上，这实际上就是 SOA 架构下的服务化。业务拆分就是把业务逻辑从一个单系统拆分到多个微服务中。

数据分片。在微服务内部将数据拆分到多个数据库上，为横向扩展增加一个新的维度。数据分片就是把一个微服务下的单个 DB 拆分成多个 DB，具备一个 Sharding 的功能。通过这样的拆解，相当于一种资源的横向扩展，从而使得整个架构可以承载更高的吞吐。

横向扩展的两种方法可以同时进行运用：交易、支付与账务三个不同微服务可以存储在不同的数据库中。另外，每个微服务内根据其业务量可以再拆分到多个数据库中，各微服务可以相互独立地进行扩展。

Seata 关注的就是微服务架构下的数据一致性问题，是一整套的分布式事务解决方案。Seata 框架包含两种模式，一种是 AT 模式。AT 模式主要从数据分片的角度，关注多 DB 访问的数据一致性，当然也包括多服务下的多 DB 数据访问一致性问题。
另外一个就是 TCC 模式，TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调用的一致性问题，保证读资源访问的事务属性。

今天我们主要讲的就是 TCC 模式。在讲 TCC 之前1.2 AT 模式

对于 AT 模式，之前其他同学已经分享过很多次，大家也应该比较熟悉了。AT 模式下，把每个数据库被当做是一个 Resource，Seata 里称为 DataSource Resource。业务通过 JDBC 标准接口访问数据库资源时，Seata 框架会对所有请求进行拦截，做一些操作。每个本地事务提交时，Seata RM（Resource Manager，资源管理器） 都会向 TC（Transaction Coordinator，事务协调器） 注册一个分支事务。当请求链路调用完成后，发起方通知 TC 提交或回滚分布式事务，进入二阶段调用流程。此时，TC 会根据之前注册的分支事务回调到对应参与者去执行对应资源的第二阶段。TC 是怎么找到分支事务与资源的对应关系呢？每个资源都有一个全局唯一的资源 ID，并且在初始化时用该 ID 向 TC 注册资源。在运行时，每个分支事务的注册都会带上其资源 ID。这样 TC 就能在二阶段调用时正确找到对应的资源。

这就是我们的 AT 模式。简单总结一下，就是把每个数据库当做一个 Resource，在本地事务提交时会去注册一个分支事务。

1.3 TCC 模式

那么对应到 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 方法。

在讲完了整个框架模型以后，大家可能会问 TCC 三个接口怎么实现。因为框架本身很简单，主要是扫描 TCC 接口，注册资源，拦截接口调用，注册分支事务，最后回调二阶段接口。最核心的实际上是 TCC 接口的实现逻辑。下面我将根据蚂蚁金服内部多年的实践来为大家分析怎么实现一个完备的 TCC 接口。，我们先回顾一下 AT 模式，这样有助于我们理解后面的 TCC 模式。

2 TCC 业务模式与并发控制

2.1 TCC 设计原则