3大主流分布式事务框架详解（图文总结）

1 简要介绍

随着微服务架构的不断发展，分布式系统逐渐普及到后端领域的每一个角落。
在分布式系统中，跨多个服务的数据一致性一直是一个重大挑战，为解决这一挑战，分布式事务应运而生。
作者在之前的文章《五种分布式事务解决方案》和《4大主流分布式算法介绍》中，详细介绍了分布式事物的解决方案以及实现原理。接下来，咱们详细介绍下行业内主流的几个分布式事务框架，以及他们的实现原理。

2 主流分布式事务框架

2.1 Seata

Seata是一款由阿里巴巴开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。它解决了分布式系统中的数据一致性问题，帮助开发者在分布式场景下实现ACID事务的支持。

2.1.1 核心组件

Seata 包含三个核心组件：

1. Transaction Coordinator (TC)：事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。
2. Transaction Manager (TM)：事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。
3. Resource Manager (RM)：资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

以上三个组件相互协作，TC 以 Seata 服务器（Server）形式独立部署，来协调各个微服务分支的事务状态，保证全局的事务执行。TM 和 RM 则是以 Seata Client 的形式集成在微服务中运行。
下面用一张图来说明：

工作流程如下：

• TM 向 TC 申请创建一个全局事务，创建成功后，同步生成一个全局唯一的 XID。此时全局事务已开启。
• XID 通过服务的调用链传递到其他服务
• RM 向 TC 注册一个分支事务，并将其纳入 XID 对应全局事务的管辖
• TM 根据 TC 收集的各个分支事务的执行结果，向 TC 发起全局事务提交或回滚决议
• TC 调度 XID 下管辖的所有分支事务，如果都成功则完成提交，否则回滚操作

2.1.2 工作模式

Seata 支持三种工作模式：

1. AT模式（基于支持本地ACID事务的数据库）：

   • 无需侵入业务代码，基于数据层
   • 两阶段提交协议的变种
   • 性能较好，但存在脏回滚的风险（回滚日志的生成和清理）

2. TCC模式（Try-Confirm-Cancel）：

   • 侵入业务代码
   • 开发者需要编写Try、Confirm、Cancel接口
   • 无锁，高性能

3. Saga模式：

   • 长事务解决方案
   • 通过事件驱动的方式，允许业务自定义正向和补偿操作
   • 适用于业务流程长、业务流程多、参与方多的场景

2.1.3 核心特性

1. 高性能：Seata 采用了高效的通信协议和事务处理机制，确保在高并发场景下依然能够保持高性能。
2. 简单易用：Seata 提供了简单易用的API和配置，开发者可以快速集成和使用。
3. 扩展性：Seata 支持灵活的扩展机制，可以根据业务需求定制各种扩展组件。
4. 社区支持：作为阿里巴巴开源项目，Seata 得到了广泛的社区支持和贡献。

2.2 ByteTCC

ByteTCC 是一个基于 TCC（Try/Confirm/Cancel）机制的分布式事务管理器。它旨在解决微服务架构下分布式事务的一致性问题，通过将事务拆分为多个阶段（Try、Confirm、Cancel）来确保事务的原子性。ByteTCC 兼容 JTA 规范，可以很好地与 EJB、Spring 等容器进行集成。值得注意的是，相对于通用事务工框架Seata，ByteTCC更专注于TCC模式，与Java生态结合的非常好。

2.2.1 工作原理

ByteTCC 的工作原理基于 TCC 模式，将事务分为三个阶段：

1. Try 阶段：在此阶段，事务参与者尝试执行事务的一部分，并记录相应的状态和数据。如果所有参与者的 Try 阶段都成功，则进入 Confirm 阶段；否则，进入 Cancel 阶段。
2. Confirm 阶段：在此阶段，如果 Try 阶段成功，则参与者将确认事务的执行，并进行最终的提交。如果 Confirm 阶段成功，则全局事务提交；否则，根据失败情况决定是回滚还是进行补偿操作。
3. Cancel 阶段：如果 Try 阶段失败或 Confirm 阶段出现问题，则进入 Cancel 阶段。在此阶段，参与者将进行事务的回滚，以确保数据的一致性。

2.2.2 核心特性

1. 支持多种事务机制：ByteTCC 支持普通事务、TCC 事务、Saga 事务等事务机制，以适应不同的业务需求。
2. 跨应用、跨服务器支持：ByteTCC 支持多数据源、跨应用、跨服务器等分布式事务场景，确保数据在分布式环境下的一致性。
3. 长事务处理：ByteTCC 适用于处理耗时较长但仍需保持事务性的操作。
4. 支持多种服务框架：ByteTCC 支持 Dubbo 和 Spring Cloud 等主流服务框架，使得开发者能够在不同框架下轻松启用分布式事务。
5. 声明式事务管理：通过简单的注解，开发者可以将普通服务转换为 TCC 服务，降低开发难度。

2.2.3 存在的缺点

• 服务侵入性强，每个事务都必须实现 Try、Confirm、Cancel 三个方法，成本高
• 为了保证事务一致性，Try、Confirm、Cancel 接口必须实现幂等
• 记录事务日志，必定会损耗一定的性能，并使得整个 TCC 事务时间拉长

2.2.4 应用场景

ByteTCC 可广泛应用于金融、电商等领域，尤其适用于涉及多个服务交互的复杂交易场景，例如资金转账、订单创建等。通过其强大功能，可以确保在分布式环境中实现事务的一致性和可靠性，有效防止数据不一致的问题。

2.3 TCC-Transaction

TCC-Transaction：华为开源的分布式事务框架，基于TCC补偿机制实现，支持高性能和高可用，提供了简单易用的API接口和工具支持。
可以扩展阅读下这篇文章《TCC-Transaction分布式事务》，写的比较清楚，我这边就不赘述了。

3 总结

无论哪种事务框架，目标无非是实现分布式系统的数据一致性。当然代价也是有的，比如
服务侵入，成本提升、性能开销等，都需要衡量。使用前可以先期调研，选择最适合的框架。