3大主流分布式事务框架详解(图文总结)
1 简要介绍
随着微服务架构的不断发展,分布式系统逐渐普及到后端领域的每一个角落。
在分布式系统中,跨多个服务的数据一致性一直是一个重大挑战,为解决这一挑战,分布式事务应运而生。
作者在之前的文章《五种分布式事务解决方案》和《4大主流分布式算法介绍》中,详细介绍了分布式事物的解决方案以及实现原理。接下来,咱们详细介绍下行业内主流的几个分布式事务框架,以及他们的实现原理。
2 主流分布式事务框架
2.1 Seata
Seata是一款由阿里巴巴开源的分布式事务解决方案,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。它解决了分布式系统中的数据一致性问题,帮助开发者在分布式场景下实现ACID事务的支持。
2.1.1 核心组件
Seata 包含三个核心组件:
- Transaction Coordinator (TC):事务协调者,维护全局和分支事务的状态,驱动全局事务提交或回滚。
- Transaction Manager (TM):事务管理器,定义全局事务的范围:开始全局事务、提交或回滚全局事务。
- 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 支持三种工作模式:
-
AT模式(基于支持本地ACID事务的数据库):
- 无需侵入业务代码,基于数据层
- 两阶段提交协议的变种
- 性能较好,但存在脏回滚的风险(回滚日志的生成和清理)
-
TCC模式(Try-Confirm-Cancel):
- 侵入业务代码
- 开发者需要编写Try、Confirm、Cancel接口
- 无锁,高性能
-
Saga模式:
- 长事务解决方案
- 通过事件驱动的方式,允许业务自定义正向和补偿操作
- 适用于业务流程长、业务流程多、参与方多的场景
2.1.3 核心特性
- 高性能:Seata 采用了高效的通信协议和事务处理机制,确保在高并发场景下依然能够保持高性能。
- 简单易用:Seata 提供了简单易用的API和配置,开发者可以快速集成和使用。
- 扩展性:Seata 支持灵活的扩展机制,可以根据业务需求定制各种扩展组件。
- 社区支持:作为阿里巴巴开源项目,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 模式,将事务分为三个阶段:
- Try 阶段:在此阶段,事务参与者尝试执行事务的一部分,并记录相应的状态和数据。如果所有参与者的 Try 阶段都成功,则进入 Confirm 阶段;否则,进入 Cancel 阶段。
- Confirm 阶段:在此阶段,如果 Try 阶段成功,则参与者将确认事务的执行,并进行最终的提交。如果 Confirm 阶段成功,则全局事务提交;否则,根据失败情况决定是回滚还是进行补偿操作。
- Cancel 阶段:如果 Try 阶段失败或 Confirm 阶段出现问题,则进入 Cancel 阶段。在此阶段,参与者将进行事务的回滚,以确保数据的一致性。
2.2.2 核心特性
- 支持多种事务机制:ByteTCC 支持普通事务、TCC 事务、Saga 事务等事务机制,以适应不同的业务需求。
- 跨应用、跨服务器支持:ByteTCC 支持多数据源、跨应用、跨服务器等分布式事务场景,确保数据在分布式环境下的一致性。
- 长事务处理:ByteTCC 适用于处理耗时较长但仍需保持事务性的操作。
- 支持多种服务框架:ByteTCC 支持 Dubbo 和 Spring Cloud 等主流服务框架,使得开发者能够在不同框架下轻松启用分布式事务。
- 声明式事务管理:通过简单的注解,开发者可以将普通服务转换为 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 总结
无论哪种事务框架,目标无非是实现分布式系统的数据一致性。当然代价也是有的,比如
服务侵入,成本提升、性能开销等,都需要衡量。使用前可以先期调研,选择最适合的框架。