gpt4 book ai didi

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

转载 作者:撒哈拉 更新时间:2024-07-10 11:13:36 58 4
gpt4 key购买 nike

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 的形式集成在微服务中运行。 下面用一张图来说明:

image

工作流程如下:

  • 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 阶段。在此阶段,参与者将进行事务的回滚,以确保数据的一致性。

image

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 总结

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

最后此篇关于3大主流分布式事务框架详解(图文总结)的文章就讲到这里了,如果你想了解更多关于3大主流分布式事务框架详解(图文总结)的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

58 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com