Fescar

什么是分布式事务问题

首先，设想一个传统的单体应用（Monolithic App），通过 3 个 Module，在同一个数据源上更新数据来完成一项业务。

很自然的，整个业务过程的数据一致性由本地事务来保证。

随着业务需求和架构的变化，单体应用被拆分为微服务：原来的 3 个 Module 被拆分为 3 个独立的服务，分别使用独立的数据源（Pattern: Database per service）。业务过程将由 3 个服务的调用来完成。

此时，每一个服务内部的数据一致性仍有本地事务来保证。而整个业务层面的全局数据一致性要如何保障呢？这就是微服务架构下面临的，典型的分布式事务需求：我们需要一个分布式事务的解决方案保障业务全局的数据一致性。

现有的方案

业务无入侵方案

在主流的分布事务解决方案中,对业务无入侵的只有基于xa的方案,但应用XA方案存在三个方面的问题

  1. 要求数据库提供XA支持,如遇到不支持XA的(或者支持的不好,比如Mysql5.7以前的版本)的数据库就不能使用
  2. 受协议本身约束,事务资源的锁定周期长,长周期的资源锁定从业务层面来看,往往是不必要的,而且业务事务资源的管理器是数据库本身,应用层无法插手.这样形成的局面就是,基于XA的应用往往想你会比较差,而且很难优化
  3. 已落地的XA的分布式解决方案,都依托于重量级的应用服务器(Tuedo/weblogic/WebSphere等)着不适用与微服务架构

侵入业务方案

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

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

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

理想方案

不可否热,侵入业务的分布式方案都有大量的实践验证,能有效解决问题,在各行各业应用系统起重要作用.但这些方案的采用实际上都是迫于无奈.设想,如果基于XA的方案能够不那么重,并且能保证业务的性能需求,相信不会有人把分布式事务问题拿到业务层面来解决

一个理想的分布式事务解决方案应该像本地使用事务一样简单,业务逻辑只关注业务层面的需求,不需要考虑事务机制上的约束

原理和设计

我们要设计一个对业务无入侵的方案,所以从业务无入侵的XA方案来思考:是否可以在XA的基础上进行演进,解决掉XA方案面临的问题呢?

如何定义一个分布式事务

首先很自然的,我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务.全局事务的职责是协调其下管辖的分支事务,达成一致,要么一起成功提交, 要么一起失败回滚.此外通常分支事务本身就是一个满足ACID的本地事务.这是我们对分布式事务结构的基本认识,与XA是一致的.

其次与XA的模型类似,我们定义三个组件来协议分布式事务的处理过程

  • Transaction Coordinator (TC)事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚
  • Transaction Manager(TM)事务管理器,控制全局事务的边界,负责开启一个事务,并最终发起全局提交或全局回滚决议
  • Resource Manager(RM)资源管理器,控制分支事务,负责分支注册,状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚

一个分布式事务的过程

  1. TM像TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID
  2. XID在微服务调用链路的上下文中传播
  3. RM向TC注册分支事务,将其纳入XID对应全局事务的管辖
  4. TM想TC发起针对XID的全局提交回滚决议
  5. TC调度XID下管辖的全部分支事务完成提交请求

Fescar和XA的差距

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

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

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

俩段提交

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

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

设想一个正常运行的业务，大概率是 90% 以上的事务最终应该是成功提交的，我们是否可以在 Phase1 就将本地事务提交呢？这样 90% 以上的情况下，可以省去 Phase2 持锁的时间，整体提高效率。

这个设计，在绝大多数场景减少了事务持锁时间，从而提高了事务的并发度。

当然，你肯定会问：Phase1 即提交的情况下，Phase2 如何回滚呢？

分支事务如何回滚

★Phase1：

首先应用需要使用Fescar的JDBC数据源代理,也就是Fescar的RM

Fescar 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务中提交。

这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。

★Phase2：

如果决议是全局提交,此时分支事务已经完成提交,不需要同步协调处理,只需要异步清理回滚日志,phase2可以非常快速完成

如果决议是全局回滚RM收到协调器发来的回滚请求,通过XID和BranchID找到回滚日志的记录,通过回滚记录反向更新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 的实现还存在一些局限，比如：事务隔离级别最高支持到读已提交的水平，SQL 的解析还不能涵盖全部的语法等。

为了覆盖 Fescar 原生机制暂时不能支持应用场景，我们定义了另外一种工作模式。

上面介绍的 Fescar 原生工作模式称为 AT（Automatic Transaction）模式，这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MT（Manual Transaction）模式，这种模式下，分支事务需要应用自己来定义业务本身及提交和回滚的逻辑。

分支的基本行为模式

分支注册：在分支事务的数据操作进行之前，需要向协调器注册，把即将进行的分支事务数据操作，纳入一个已经开启的全局事务的管理中去，在分支注册成功后，才可以进行数据操作。

状态上报：在分支事务的数据操作完成后，需要向事务协调器上报其执行结果。

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

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

AT的模式分支的行为模式

业务逻辑不需要关注事务的机制,分支与全局事务的交互过程自动进行

MT模式分支的行为模式

业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分，形成一个 MT 分支，加入全局事务。

MT 模式一方面是 AT 模式的补充。另外，更重要的价值在于，通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。

混合模式

因为 AT 和 MT 模式的分支从根本上行为模式是一致的，所以可以完全兼容，即，一个全局事务中，可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的：AT 模式可以支持的，使用 AT 模式；AT 模式暂时支持不了的，用 MT 模式来替代。另外，自然的，MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起，纳入同一个分布式事务的管理中。

应用场景

回到我们设计的初衷：一个理想的分布式事务解决方案是不应该侵入业务的。MT 模式是在 AT 模式暂时不能完全覆盖所有场景的情况下，一个比较自然的补充方案。我们希望通过 AT 模式的不断演进增强，逐步扩大所支持的场景，MT 模式逐步收敛。未来，我们会纳入对 XA 的原生支持，用 XA 这种无侵入的方式来覆盖 AT 模式无法触达的场景。

扩展点

微服务支持

事务上下文在微服务间的传播需要根据微服务框架本身的机制，订制最优的，对应用层透明的解决方案。有兴趣在这方面共建的开发者可以参考内置的对 Dubbo 的支持方案，来实现对其他微服务框架的支持。

支持数据库类型

因为 AT 涉及 SQL 的解析，所以在不同类型的数据库上工作，会有一些特定的适配。有兴趣在这方面共建的开发者可以参考内置的对 MySQL 的支持方案，来实现对其他数据库的支持。

配置服务注册发现

支持接入不同的配置和服务注册发现解决方案。比如：Nacos、Eureka、ZooKeeper 等。

MT模式的场景拓展

MT 模式的一个重要作用就是，可以把非关系型数据库的资源，通过 MT 模式分支的包装，纳入到全局事务的管辖中来。比如，Redis、HBase、RocketMQ 的事务消息等。有兴趣在这方面共建的开发者可以在这里贡献一系列相关生态的适配方案。

事务协调器的分布式高可用方案

针对不同场景，支持不同的方式作为事务协调器 Server 端的高可用方案。比如，针对事务状态的持久化，可以是基于文件的实现方案，也可以是基于数据库的实现方案；集群间的状态同步，可以是基于 RPC 通信的方案，也可以是基于高可用 KV 存储的方案。

绿色部分是已经开源发布出来的，黄色 部分是将在后续版本中由阿里发布出来的，蓝色部分是我们和社区共建生态部分：

  • 对不同数据库的支持，开发者可以参考 MySQL 的实现。
  • 对不同微服务框架的支持，开发者可以参考 Dubbo 的实现。对 MQ、NoSQL 的支持，开发者可以参考 TCC 的实现。
  • 配置和服务注册发现：开发者通过少量的工作可以接入任何可以提供这类服务的框架。
  • 当然，非 蓝色 的部分也非常欢迎社区参与进来，贡献更优的解决方案。
  • 另外，XA 作为分布式事务的标准，是一个完备的分布式事务解决方案不可或缺的，远景的规划中，我们一定需要把 XA 的支持加入进来。
Last modification：November 17, 2023
© Allow specification reprint
如果觉得我的文章对你有用，请随意赞赏