关于开源分布式事务中间件Fescar，我们总结了开发者关心的13个问题

© Mikito Tateisi

开源分布式事务中间件 Fescar 自1月10日上线v0.1版本以来，受到了开发者们的极大关注(watch249，star3005，fork649，社区讨论的issue58，数据统计于1月17日14:00)，可见，天下苦分布式事务久矣。

为此，我们收集了大家在社区(Github)和社群关注的核心问题，总结如下，并给出回复。

Q1：Fescar 的发展经历了哪些历程?和阿里云全局事务服务GTS之间是什么关系?

A1：阿里巴巴是国内最早一批进行应用分布式(微服务化)改造的企业，所以很早就遇到微服务架构下的分布式事务问题。

• 2014 年

阿里巴巴中间件团队发布TXC(Taobao Transaction Constructor)，为集团内应用提供分布式事务服务。

• 2016 年

TXC 经过产品化改造，以GTS(Global TransactionService)的身份上线阿里云，成为当时业界唯一一款云上分布式事务产品，以阿里云公有云或专有云解决方案的形式，交付给众多外部客户。

• 2019 年

基于 TXC 和 GTS 的技术积累，阿里巴巴中间件团队发起了开源项目Fescar(Fast & EaSy Commit And Rollback, FESCAR)，和社区一起建设这个分布式事务解决方案。

TXC/GTS/Fescar一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。

Q2：Fescar 有哪些适用场景?

A2：Fescar 的愿景是让分布式事务的使用像现在本地事务的使用一样简单、高效，最终的目标是希望可以适用于所有的分布式事务场景。目前，核心的 AT 模式适用于构建于支持本地 ACID 事务的关系型数据库。非关系型数据库类资源的管理，通过 MT 模式来支持。AT 模式与 MT 模式完全兼容，所以可以在同一个分布式事务中，同时管理两类资源。

Q3：目前有已经有一些其他的分布式事务开源方案，Fescar 和他们之间有哪些区别?和JTA支持分布式事务有哪些区别?

A3：既有的分布式事务解决方案按照对业务侵入性分为两类，即：对业务无侵入的和对业务有侵入的。

• 业务无侵入的方案

既有的主流分布式事务解决方案中，对业务无侵入的只有基于 XA 的方案(注：问题中提到的 JTA 是XA 方案的 Java 版本)，但应用XA 方案存在 3 个方面的问题：

1、要求数据库提供对 XA 的支持。如果遇到不支持 XA(或支持得不好，比如 MySQL 5.7 以前的版本)的数据库，则不能使用。

2、受协议本身的约束，事务资源(数据记录、数据库连接)的锁定周期长。长周期的资源锁定从业务层面来看，往往是不必要的，而因为事务资源的管理器是数据库本身，应用层无法插手。这样形成的局面就是，基于 XA 的应用往往性能会比较差，而且很难优化。

3、已经落地的基于 XA 的分布式解决方案，都依托于重量级的应用服务器(Tuxedo/WebLogic/WebSphere 等)，这是不适用于微服务架构的。

• 侵入业务的方案

实际上，最初分布式事务只有 XA 这个唯一方案。XA 是完备的，但在实践过程中，由于种种原因(包含但不限于上面提到的3 点)往往不得不放弃，转而从业务层面着手来解决分布式事务问题。比如：

• 基于可靠消息的最终一致性方案
• TCC
• Saga

都属于这一类。这些方案的具体机制在这里不做展开，网上这方面的论述文章非常多。总之，这些方案都要求在应用的业务层面把分布式事务技术约束考虑到设计中，通常每一个服务都需要设计实现正向和反向的幂等接口。这样的设计约束，往往会导致很高的研发和维护成本。

不可否认，侵入业务的分布式事务方案都经过大量实践验证，能有效解决问题，在各行种业的业务应用系统中起着重要作用。但回到原点来思考，这些方案的采用实际上都是迫于无奈。

回到问题：

与基于消息的最终一致、TCC、Saga等业务逻辑侵入方案的不同在于，Fescar 的设计初衷就是保持对业务的非侵入性，不要求业务层面按照分布式事务的特定场景来设计正向和反向的两套(甚至多套)业务逻辑。这方面的差别就不展开了。

与 XA 的区别在于，设计了一套不同与 XA 的两阶段协议，在保持对业务不侵入的前提下，保证良好的性能，也避免了对底层数据库协议支持的要求。可以看作是一套轻量级的XA 机制。具体的差别如下：

• 架构层次

XA方案的 RM 实际上是在数据库层，RM本质上就是数据库自身(通过提供支持 XA 的驱动程序来供应用使用)。

而 Fescar 的RM 是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。

这个设计，剥离了分布式事务方案对数据库在协议支持上的要求。

• 两阶段提交

先来看一下 XA 的2PC 过程。

无论 Phase2 的决议是commit 还是 rollback，事务性资源的锁都要保持到Phase2 完成才释放。

再看 Fescar 的2PC 过程。

分支事务中数据的 本地锁 由本地事务管理，在分支事务 Phase1 结束时释放。

同时，随着本地事务结束，连接 也得以释放。

分支事务中数据的 全局锁 在事务协调器侧管理，在决议 Phase2 全局提交时，全局锁马上可以释放。只有在决议全局回滚的情况下，全局锁 才被持有至分支的 Phase2 结束。

这个设计，极大地减少了分支事务对资源(数据和连接)的锁定时间，给整体并发和吞吐的提升提供了基础。

Q4：Fescar 支持 Dubbo 的哪些版本?

A4：所有版本。

Q5：Fescar 支持 Spring Cloud么?

（编辑：ASP站长网）