Seata 2.x 系列【4】产品简介

有道无术，术尚可求，有术无道，止于术。

本系列Spring Boot 版本 3.1.0

本系列Seata 版本 2.0.0

源码地址：https://gitee.com/pearl-organization/study-seata-demo

1. 概述

官方文档
GitHub地址

Seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

2. 发展历史

2007 年，阿里巴巴和蚂蚁集团内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题。内部项目分别被称为 TXC (Taobao Transaction Constructor)、XTS(eXtended Transaction Service)，该项目几乎在每笔订单的交易支付链路几乎都有使用。

自 2013 年以来，阿里巴巴和蚂蚁集团已在阿里云和金融云上向企业客户分别发布了分布式事务云服务产品 GTS(global transaction service)、DTX(Distributed Transaction-eXtended)，在各个行业领域积累了大量用户。

2019 年 1 月，阿里巴巴集团正式开源了该项目，项目命名为 Fescar (Fast & Easy Commit and Rollback）。项目开源以来，它受到了众多开发人员的热烈欢迎和赞扬，开源一周收获了超 3k star，曾一度蝉联 GitHub Trending 排行榜第一。

2019 年 4 月，蚂蚁集团数据中间件团队加入了 Fescar 社区。为了创建一个更加开放和中立的社区，Fescar 改名为 Seata（Simple Extensible Autonomous Transaction Architecture），代码仓库从 Alibaba organization 迁移到其独立的 Seata organization。

2019 年 12 月，Seata 开源项目正式发布 1.0.0 GA 版本，标志着项目已基本可生产使用。

2023 年 10 月，为了更好的通过社区驱动技术的演进，阿里和蚂蚁集团正式将 Seata 捐赠给 Apache 基金会，该提案已通过了 Apache 基金会的投票决议，Seata 正式进入 Apache 孵化器。

3. 核心术语

3.1 TC

Transaction Coordinator事务协调者，是一个需要独立部署的中间件服务，对应的是Seata的服务端，分布式事务流程中TC和TM、RM进行交互，负责维护全局和分支事务的状态，驱动全局事务提交或回滚。

3.2 TM

Transaction Manager事务管理器，分布式事务流程中对应的是事务的发起方（一般是业务应用程序发起），负责定义全局事务的范围，包括开始全局事务、提交或回滚全局事务。

3.3 RM

Resource Manage资源管理器，分布式事务流程中对应的是分支事务的参与者（业务应用程序），负责管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

4. 事务模式

下面简单介绍下Seata支持的事务模式，具体流程和案例会在后续单独介绍。

4.1 AT 模式

AT 模式是 Seata 创新的一种非侵入式的分布式事务解决方案，Seata 在内部做了对数据库操作的代理层，我们使用 Seata AT 模式时，实际上用的是Seata自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，比如插入回滚 undo_log 日志，检查全局锁等。

AT 模式是两阶段提交协议的演变，整体机制如下：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：
  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

4.2 TCC 模式

TCC 模式是 Seata 支持的一种由业务方细粒度控制的侵入式分布式事务解决方案，是继AT模式后第二种支持的事务模式，最早由蚂蚁金服贡献。其分布式事务模型直接作用于服务层，不依赖底层数据库，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的SOA服务而设计的。

优点：TCC 完全不依赖底层数据库，能够实现跨数据库、跨应用资源管理，可以提供给业务方更细粒度的控制。

缺点：TCC 是一种侵入式的分布式事务解决方案，需要业务系统自行实现 Try，Confirm，Cancel 三个操作，对业务系统有着非常大的入侵性，设计相对复杂。

适用场景：TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。

4.3 Saga 模式

Saga 模式是 SEATA 提供的长事务解决方案，在 Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

优点：

• 一阶段提交本地事务，无锁，高性能
• 事件驱动架构，参与者可异步执行，高吞吐
• 补偿服务易于实现

缺点：

• 不保证隔离性

适用场景：

• 业务流程长、业务流程多
• 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

4.4 XA 模式

XA 模式是从1.2版本支持的事务模式。XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。

优势：

• 与 Seata 支持的其它事务模式不同，XA 协议要求事务资源本身提供对规范和协议的支持，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。
• 业务无侵入，和 AT 一样，XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担。
• 数据库的支持广泛，XA 协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。

缺点：

• XA prepare 后，分支事务进入阻塞阶段，收到XA commit或 XA rollback 前必须阻塞等待。事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，性能差。

适用场景： 适用于想要迁移到Seata平台基于 XA 协议的老应用，使用 XA 模式将更平滑，还有 AT 模式未适配的数据库应用。

5. 注册中心

注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

Seata Server端也就是TC，Seata Client端也就是TM、RM，它们之间需要互相通信，这时可以使用注册中心暴露双方地址。

Seata支持以下注册中心：

• Nacos
• Eureka
• Consul
• Etcd
• Zookeeper
• Sofa
• Redis
• File (直连)

6. 配置中心

配置中心可以说是一个"大货仓"，内部放置着各种配置文件，你可以通过自己所需进行获取配置加载到对应的客户端，比如Seata Client、Seata Client会去读取全局事务开关，事务会话存储模式等配置信息。

Seata支持以下配置中心：

• Nacos
• Consul
• Apollo
• Etcd
• Zookeeper
• File (读本地文件, 包含conf、properties、yml配置文件的支持)

7. 数据库类型支持

AT模式支持的数据库有：MySQL、Oracle、PostgreSQL、 TiDB、MariaDB。2.0 版本新增了达梦、SQLServer 和PolarDB-X 2.0数据库支持。

TCC模式不依赖数据源(1.4.2版本及之前)，1.4.2版本之后增加了TCC防悬挂措施，需要数据源支持。

Saga模式不依赖数据源。

XA模式只支持实现了XA协议的数据库。Seata支持MySQL、Oracle、PostgreSQL和MariaDB。

8. ORM 框架支持

Seata 虽然是保证数据一致性的组件，但对于 ORM 框架并没有特殊的要求，像主流的Mybatis、Mybatis-Plus、Spring Data JPA、 Hibernate等都支持。这是因为ORM框架位于JDBC结构的上层，而 Seata 的 AT、XA 事务模式是对 JDBC 标准接口操作的拦截和增强。

9. 微服务框架支持

Seata 的事务上下文由 RootContext 来管理。应用开启一个全局事务后，RootContext 会自动绑定该事务的 XID，事务结束（提交或回滚完成），RootContext 会自动解绑 XID。

Seata全局事务的传播机制就是指事务上下文的传播，根本上，就是XID的应用运行时的传播方式。支持：

• 服务内部的事务传播，基于ThreadLocal
• 跨服务调用的事务传播， XID 通过服务调用传递到服务提供方，并绑定到 RootContext 中去

只要能传递XID，就能实现全局事务，所以理论上 Seata 可以支持任意的微服务框架。