阿里开源fescar_Fescar：阿里巴巴开源的分布式交易解决方案

最新推荐文章于 2021-11-04 20:40:46 发布

dfsgwe1231

最新推荐文章于 2021-11-04 20:40:46 发布

阅读量143

点赞数

文章标签：分布式数据库大数据编程语言区块链

原文链接：https://hackernoon.com/fescar-a-distributed-transaction-solution-open-sourced-by-alibaba-f70c9b4c72a1

版权

阿里开源fescar

为了支持基于微服务的开发，阿里巴巴现在推出了Fescar，这是其全球交易服务解决方案的开源版本，用于解决分布式交易问题。

本文是 阿里巴巴开放源代码 系列的一部分。

在在线系统中，微服务已获得开发人员的最新支持，以通过将复杂的应用程序拆分为松散耦合的服务来减少困难，增强可伸缩性并促进敏捷开发。但是，在微服务系统中实现看似简单的功能可能需要调用多个服务并操作多个数据库，从而给服务调用带来了巨大的分布式事务问题。

当前，分布式事务是实现微服务的最大障碍，也是相关技术问题中最具挑战性的。为了克服这些困难，阿里巴巴最初为其系统开发了全球交易服务（GTS）解决方案。现在，它通过发布一个名为Fescar的开源版本（“ Fast and Easy Commit and Rollback”的简称）扩展了该解决方案。

为了纪念它在GitHub上的最新发布，本文详细介绍了Fescar的基础知识及其对基于微服务的开发的支持。

分布式交易问题的由来

要了解微服务如何导致分布式事务问题，有必要考虑一下传统的单片应用程序的示例，该示例通过通过三个模块更新单个数据源上的数据来完成业务流程。自然，本地事务可确保整个业务流程中的数据一致性。

随着业务需求和体系结构的变化，单个应用程序分为微服务。最初的三个模块分为三个独立的服务，每个服务使用不同的数据源（模式：每个服务的数据库）。现在，将通过调用这三个服务来完成业务流程。

在这种情况下，本地事务仍然能够保证每个服务中的数据一致性。但是，为了确保整个业务级别的全局数据的一致性，必须使用分布式事务解决方案。

发展费斯卡

阿里巴巴是中国最早向分布式微服务过渡的企业之一，因此在微服务架构下解决分布式交易问题的历史由来已久。

2014年，阿里巴巴的中间件团队发布了淘宝交易构造器（TXC），为集团内部应用程序提供分布式交易服务。

在产品化后的2016年，TXC在阿里云上作为全球交易服务（GTS）实施，成为当时云上唯一的分布式交易产品。因此，它开始通过阿里巴巴的公共云和Apsara解决方案为许多外部客户提供服务。

进入2019年，基于TXC和GTS积累的技术，阿里巴巴的中间件团队启动了开源Fescar项目，以与开发社区合作进一步构建其分布式交易解决方案。

TXC，GTS和Fescar都来自同一起源，并且共同为微服务架构下的分布式事务问题提供了独特的解决方案。

原始设计目标

在快速发展的互联网时代，快速经受反复试验的能力对企业至关重要。一方面，将微服务和分布式事务支持引入技术基础架构不应在业务级别上产生任何额外的研发负担。另一方面，引入分布式事务支持的企业应保持基本相同的性能水平，并且不应受到事务机制的明显阻碍。

基于这些标准，Fescar的设计一开始就涉及两个关键的考虑因素。首先，它不会对业务造成任何干扰。此处的“入侵”是指由于分布式事务导致的技术问题，因此应在业务级别设计和修改应用程序。这种设计和修改通常会导致应用程序的研发和维护成本很高。阿里巴巴需要在中间件级别解决分布式事务问题，而无需在业务级别对应用程序进行额外的工作。

其次，设计需要确保高性能。分布式事务保证的引入不可避免地带来了额外的开销，从而导致性能下降。阿里巴巴需要将因引入分布式事务而造成的性能损失降低到最低水平，以使应用程序的可用性不会受到引入分布式事务的影响。

先前解决方案的缺点

先前的分布式事务解决方案可以分为对企业具有干扰性的解决方案和对企业不具有干扰性的解决方案。

在主流解决方案中，只有基于XA的解决方案对企业无干扰。但是，基于XA的解决方案存在三个问题。首先，他们要求数据库为XA提供支持；对于不支持XA或支持不佳的数据库（例如5.7之前MySQL版本），将无法使用这些解决方案。其次，它们受到协议本身的约束，并且与之相关的事务资源具有较长的锁定周期。从业务角度来看，长期资源锁定通常是不必要的，但是由于事务资源管理器是数据库本身，因此应用程序层无法干预。这导致性能差和优化困难。最后，已实现的，基于XA的分布式解决方案依赖于Tuxedo，WebLogic或WebSphere等重型应用服务器，从而使其不适用于微服务架构。

实际上，XA是早期开发过程中唯一的分布式事务解决方案。它是完整的，但实际上，出于多种原因，通常需要放弃它，包括但不限于上述问题。例如，基于可靠消息，TCC和Saga的最终一致性解决方案都属于此类。由于Internet上信息的可用性，本文中不解释这些解决方案的机制。简而言之，他们要求在应用程序设计的业务级别上考虑分布式事务技术的约束。通常，每个服务都需要设计为实现正向和反向幂等接口；这样的设计约束通常导致高的研发和维护成本。

理想解决方案的品质

侵入式分布式事务解决方案已在实践中得到广泛验证，可以有效解决问题，从而在各个行业的业务应用程序系统中发挥重要作用。尽管如此，采用这种解决方案仍应被视为遥不可及的第二选择。假设基于XA的解决方案重量更轻并且可以确保企业的性能要求，那么人们不太可能将分布式交易问题带到企业层面。

因此，理想的解决方案应该与使用本地事务一样简单，其中业务逻辑仅关注业务级别的需求，而不关注事务机制的约束。

解决方案原理与设计

将非侵入式XA解决方案视为在业务级别上非侵入式解决方案的基础，需要解决的关键问题是如何使XA适应解决所提出的问题。以下各节详细讨论了适应过程中涉及的原理。

定义分布式交易

首先，自然可以将分布式事务视为包含多个分支事务的全局事务。一项全球交易的责任是协调其管辖范围内的分支交易，以使它们达成一致，无论是成功地共同完成还是失败并一起回滚。另外，分支事务本身通常是满足ACID原则的本地事务。这是对分布式事务结构的基本了解，与XA一致。

其次，类似于XA模型，定义了三个组件来协商分布式事务的处理：

事务协调器（TC）维护全局事务的运行状态，并负责协调和驱动全局事务的提交或回滚。

事务管理器（TM）控制全局事务的边界，负责打开全局事务，并最终启动全局提交或全局回滚解决方案。

资源管理器（RM）控制分支事务，负责分支注册和状态报告，并从事务协调器接收指令以驱动分支（本地）事务的提交和回滚。

典型的分布式事务处理过程如下：

1. TM要求TC打开一个全局事务并创建该全局事务，从而成功生成一个全局唯一的XID。

2. XID在微服务调用链接的上下文中传播。

3. RM向TC注册分支事务，并将其合并到与XID对应的全局事务的管辖权中。

4. TM启动针对TC的XID的全局提交或回退解决方案。

5. TC调度XID下的所有分支事务以完成提交或回滚请求。

到目前为止，Fescar的协议机制通常与XA一致。

Fescar和XA之间的区别

Fescar与XA的第一个主要区别是在体系结构级别。

XA解决方案的RM实际上是在数据库级别，RM本质上是数据库本身（可通过提供启用XA的驱动程序供应用程序使用）。

Fescar的RM以第二方包的形式作为中间件层部署在应用程序端。它不依赖于数据库本身提供的XA协议支持，也不需要数据库支持该协议。这对于微服务体系结构非常重要：应用程序层无需针对两种不同的本地事务和分布式事务场景调整两个不同的数据库驱动程序。此设计原则剥夺了分布式事务解决方案对协议的数据库支持的要求。

Fescar的第二个主要差异涉及两阶段提交。下面显示了XA的2PC流程：

无论阶段2的解决方案是提交还是回滚，事务资源锁都将保留到阶段2完成。

想象正常的业务很有可能最终成功完成90％以上的交易。可以在第一阶段进行本地交易吗？如果百分比超过90％，则提早提交可以节省第二阶段的锁定时间并提高整体效率。

如上所示，Fescar的设计在大多数情况下减少了事务锁定时间，从而增加了事务的并发性。

下一个问题当然是，在提交阶段1时，阶段2如何回滚？

分支事务如何提交和回滚

首先，应用程序需要使用Fescar的JDBC数据源代理，即Fescar的RM。

第1阶段的工作方式如下：通过分析业务SQL，Fescar的JDBC数据源代理将在SQL执行之前和之后的业务数据的数据映像组织到撤消日志中，并使用本地事务的ACID功能来编写业务更新。业务数据和撤消日志将在同一本地事务中提交。通过这种方式，可以确保已提交的业务数据的任何更新肯定具有相应的撤消日志。

基于此机制，可以在全局事务的第1阶段中提交分支的本地事务，而可以立即释放由本地事务锁定的资源。

阶段2的工作方式如下：如果解决方案是全局提交，则分支事务当时已经完成了提交，因此不需要同步对帐。（仅回滚日志需要异步清除）。因此，第二阶段可以很快完成。

如果解决方案是全局回滚，则RM从协调器接收回滚请求，通过XID和Branch ID查找相应的撤消日志记录，并生成反向更新SQL，然后通过回滚该记录以完成分支来执行该更新SQL。回滚。

事务传播机制

XID是全局事务的唯一标识符。事务传播机制需要通过服务调用链接传递XID，并将其绑定到服务的事务上下文。这样，服务链接中的数据库更新操作将由XID表示的全局事务进行注册，并包含在同一全局事务的权限中。

基于此机制，Fescar可以支持任何微服务RPC框架，只要它在特定框架中找到可以透明地传播XID的机制即可，例如Dubbo的Filter + RpcContext。

对应于Java EE规范和Spring定义的事务传播属性，Fescar支持和不支持的传播如下：

·PROPAGATION_REQUIRED：默认情况下受支持

·PROPAGATION_SUPPORTS：默认情况下受支持

·PROPAGATION_MANDATORY：通过API支持

·PROPAGATION_REQUIRES_NEW：通过API支持

·PROPAGATION_NOT_SUPPORTED：通过API支持

·PROPAGATION_NEVER：通过API支持

·PROPAGATION_REQUIRED_NESTED：不支持

隔离

全局事务的隔离基于分支事务的本地隔离级别。

基于数据库本地隔离级别为“读提交”或更高的前提，Fescar设计为使用由事务协调器维护的全局写互斥锁，以确保事务之间的写隔离，并且默认情况下在隔离级别为“读取未提交”。

关于隔离级别的共识是，大多数应用程序在“读取已提交”的隔离级别下都可以正常工作。实际上，在大多数情况下，应用程序在“未提交读”的隔离级别下工作也没有问题。

在极端情况下，如果应用程序需要达到已提交的全局读取的状态，Fescar还将提供一种实现该目标的机制。默认情况下，Fescar在“未提交读”的隔离级别下工作，从而确保大多数情况下的效率。

交易的ACID属性在Fescar中是一个复杂的话题，将在以后的文章中进行深入说明。

应用场景分析

上面提到的Fescar核心原则的一个重要前提是，分支交易中涉及的资源必须是支持ACID交易的关系数据库。分支提交和回滚机制取决于本地事务的保证。因此，如果应用程序使用的数据库不支持事务或根本不是关系数据库，则Fescar不适用。

此外，Fescar的实施还存在一些限制。例如，支持事务隔离级别，直到读取已提交级别为止。 SQL解析未涵盖所有语法；等等。

为了弥补Fescar本机机制当前无法解决的缺陷，定义了另一种工作模式。上述的Fescar本机工作模式称为AT（自动交易）模式，该模式对企业无干扰。与此相对应的另一种工作模式是MT（手动交易）模式，其中业务需要定义分支交易。

基本分支行为

作为全局事务的一部分的分支事务，除了其自身的业务逻辑之外，还包括与协调器交互的四个动作：

·分支注册：在执行其数据操作之前，分支事务需要向协调器进行注册，以使即将发生的数据操作可以包含在已打开的全局事务的管理中。分支注册成功后，即可操作数据。

·状态报告：完成其数据操作后，分支事务必须将执行结果报告给事务协调器。

·分支提交：分支事务响应协调器发出的此类请求来完成分支提交。

·分支回滚：分支事务响应协调器发出的此类请求完成分支回滚。

AT分支行为模式

业务逻辑不关注事务机制，分支与全局事务之间的交互过程是自动执行的。

MT分支行为模式

需要将业务逻辑分为三部分以形成MT分支并加入全局事务：准备，提交和回滚。

一方面，MT模式与AT模式互补。另一方面，它的更重要的价值是通过它的许多非事务性资源可以将其包括在全局事务的管理中。

混合模式

因为AT分支和MT分支的行为模式在根本上是一致的，所以它们是完全兼容的。也就是说，在全球交易中，AT和MT分支都可以存在。这样，可以实现针对业务场景的全面覆盖的目的。对于那些支持AT模式的设备，使用AT模式。对于当前不支持AT模式的用户，将使用MT模式。另外，MT管理的非事务性资源也可以与支持事务的关系数据库资源一起包含在同一分布式事务的管理中。

应用场景展望

就Fescar的设计初衷而言，理想的分布式事务解决方案在业务级别上应该是非侵入性的。在AT模式无法完全涵盖所有情况的情况下，MT模式是自然的补充。 Fescar团队希望通过AT模式的不断发展逐步扩大支持场景的范围，而MT模式则逐渐收敛。将来，Fescar将包括对XA的本地支持，并将XA作为一种非侵入性方式来涵盖AT模式无法达到的方案。