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

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

© Mikito Tateisi

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

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

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

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

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

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

基于 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等业务逻辑侵入方案的不同在于，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么?

A5：Fescar 与微服务框架的接口点在于，需要把事务的唯一标识 XID(一个字符串)通过微服务框架的服务调用间调用的机制中，透明地传递，并通过 Fescar 的 API 来绑定(或解绑)到应用的线程上下文中。(机制可以参考内置的对 Dubbo 支持的实现com.alibaba.fescar.dubbo.TransactionPropagationFilter)所以，本质上这个问题不是支不支持Spring Cloud，而是如何支持 Spring Cloud 中选用的服务调用机制。目前正在和 Spring Cloud Alibaba 的同学合作，准备在v0.5.x版本(或更早)发布对 Spring Cloud默认的支持。同时，非常欢迎社区的朋友参与进来，贡献包括 Spring Cloud 在内的各类微服务框架的支持。

Q6：Fescar 是否支持本地跨库多数据源?除了关系型数据库，是否还支持NoSQL数据库?

A6：本地跨多数据源同样是支持的，在 Fescar 的架构中，同一个服务中的多个数据源与跨服务的多个数据源，没有本质区别。AT 模式目前仅限于对关系型数据库的支持(本身具备ACID 事务支持)，后面会发布出来的 MT 模式可以支持 NoSQL 这类本身不具备本地事务支持的资源。

Q7：Fescar 现在开源的是AT模式，MT模式暂时不支持，什么时候会开源?

A7：当前 0.1.0 版本只是把 Fescar 最核心的 AT 模式的最小集发布出来，一方面是按开源的规划和架构的重构进展，另一方面也是希望通过最小集版本，让用户和开发者社区更容易理解到我们核心的设计思路，让更多人比较容易地参与进来建设，而不是完全由阿里巴巴主导，仅仅把我们的整套方案开源出来给大家用而已。阿里巴巴在分布式事务上的技术积累，我们会通过 Fescar 项目毫无保留地贡献给社区，所有功能特性都会按规划和社区的反馈陆续开源出来。MT 按初步的计划，会在0.5.x 版本发布。

Q8：Fescar 什么时候提供HA cluster，单节点的server的瓶颈如何处理?

A8：按初步的计划，HA Cluster 会在 0.5.x 版本发布，解决单机部署的单点问题。

Q9：因网络中断、网张闪断、节点宕机和超时等引起的异常，Fescar会提供相应的补偿措施么?

A9：这些异常情况的处理是分布式事务解决方案的基本要求，Fescar 同样也是提供了整套方案来处理各类异常场景。这方面的具体机制会在 HA Cluster 版本发布时，给出全面的分析介绍。

Q10：Fescar框架中，如何监控分布式事务?

A10：监控是非常重要的一块儿内容。TXC 和 GTS 的监控在阿里巴巴内部使用了很多基础设施的辅助。而在开源版本中，我们还没有一个现成的监控方案。大体上，监控的基础是两个方面：一方面是日志，通过日志的采集和处理，可以形成一个完整的事务链路，这些数据对于业务层面的分析和调优是重要的参考依据。另一方面是 API，Fescar 会提供一套管控 API，用于对运行时事务的管理。我们后续会把这两方面的数据格式、部署形态及接口整理出来，希望和社区来共建监控这个重要的方面。

Q11：Fescar 的roadmap 有了么?

A11：目前最新的roadmap如下：

当然，项目迭代演进的过程，我们最重视的是社区的声音，路线图会和社区充分交流及时进行调整。

Q12：Fescar 官网什么时候上线?

A12：Fescar 官方域名已经注册，官网将采用静态开源站点搭建工具Docsite「传送门」进行搭建，logo 已经设计并将于近期公布。

Q13：如何加入 Fescar 社区，进行贡献，已经摩拳擦掌了。

A13：我们非常欢迎大家通过各种形式参与到我们项目的建设中，包括但不限于：

具体的参与方法可以参见我们项目中的CONTRIBUTING 指引，或与 @[emailprotected]联系。实际上，我们并不拘泥于贡献的形式，开发者提出的每一个 issue，无论是Bug Report、改进建议或者甚至是问题咨询都代表着对项目的关注和帮助。希望 Fescar 项目和社区一起健康成长，成为分布式事务领域一个优秀的解决方案。

java中的这些名词都是什么？

JNDI(Java Naming and Directory Interface，Java命名和目录接口)是一组在Java应用中访问命名和目录服务的API。 命名服务将名称和对象联系起来，使得我们可以用名称访问对象。 目录服务是一种命名服务，在这种服务里，对象不但有名称，还有属性。 jms即Java消息服务（Java Message Service）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。 jms同时也可以指Journal of Marketing Science，《营销科学学报》的简称。 此外，佳木斯、姐妹们的拼音缩写也是jms。 JTA，即Java Transaction API，译为Java事务API。 JTA允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。 JDBC驱动程序的JTA支持极大地增强了数据访问能力。 JAF,即为JavaBeans Activation Framework的缩写。 Mail API 的所有版本都需要 JavaBeans Activation Framework 来支持任意数据块的输入及相应处理。 功能似乎不多，但目前许多浏览器和邮件工具中都能找到这种基本的 MIME 型支持。 文件就是JAF的框架jar包。 JAF是一个专用的数据处理框架，它用于封装数据，并为应用程序提供访问和操作数据的接口。 JAF的主要作用在于让java应用程序知道如何对一个数据源进行查看、编辑和打印等操作。 对于通过JAF封装的数据，应用程序通过JAF提供的接口可以完成如下功能： 1、访问数据源中的数据. 2、获知数据源的数据类型. 3、获知可对数据进行的各种操作. 4、用户对数据执行某种操作时，自动创建执行该操作的软件部件的实例对象. javaMail API可以利用JAF从某种数据源中读取数据和获知数据的MIME类型，并用这些数据生成MIME消息中的消息体和消息类型。 RMI是Java的一组拥护开发分布式应用程序的API。 RMI使用Java语言接口定义了远程对象，它集合了Java序列化和Java远程方法协议(Java Remote Method Protocol)。 简单地说，这样使原先的程序在同一操作系统的方法调用，变成了不同操作系统之间程序的方法调用，由于J2EE是分布式程序平台，它一RMI机制实现程序组件在不同操作系统之间的通信。 比如，一个EJB可以通过RMI调用Web上另一台机器上的EJB远程方法。 RMI（Remote Method Invocation，远程方法调用）是用Java在JDK1.1中实现的，它大大增强了Java开发分布式应用的能力。 Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。 其实它可以被看作是RPC的Java版本。 但是传统RPC并不能很好地应用于分布式对象系统。 而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。 SOAP：简单对象访问协议，简单对象访问协议（SOAP）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。 SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。 它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。

svn和git的区别

区别1、GIT是分布式的，SVN不是这是GIT和其它非分布式的版本控制系统，最核心的区别；GIT跟SVN一样有自己的集中式版本库或服务器。 但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chectout代码后会在自己的机器上克隆一个自己的版本库。 区别2、Git直接记录快照，而非差异比较Git和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。 Git 并不保存这些前后变化的差异数据。 实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。 每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照 的索引。 为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一链接。 区别3、近乎所有操作都是本地执行在 Git 中的绝大多数操作都只需要访问本地文件和资源，不用连网。 但如果用 CVCS 的话，差不多所有操作都需要连接网络。 因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快。

JAVA的先进技术有哪些？

毫无疑问，主流的技术当属J2EE，虽然说现在J2EE的规范已经到Java EE 5，但现在企业的应用大多还是属于J2EE 1.4规范，JDBC、 JNDI、 EJB、 RMI、 JSP、 Java servlets、 XML、 JMS、 Java IDL、 JTS、 JTA, JavaMail 和 JAF等都属于J2EE的范畴。另外，也有一些开源的技术趋于流行，比如Spring，Struts，Hibernate等