河间市网站建设公司,做网站应达到什么效果,wordpress 不能拖动了,域名收录提交入口广为人知的阿里分布式事务解决方案#xff1a;GTS#xff08;Global Transaction Service#xff09;#xff0c;已正式推出开源版本#xff0c;取名为“Fescar”#xff0c;希望帮助业界解决微服务架构下的分布式事务问题#xff0c;今天我们一起来深入了解。 FESCAR o…广为人知的阿里分布式事务解决方案GTSGlobal Transaction Service已正式推出开源版本取名为“Fescar”希望帮助业界解决微服务架构下的分布式事务问题今天我们一起来深入了解。 FESCAR on GitHub
https://github.com/alibaba/fescar 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇系统微服务化后一个看似简单的功能内部可能需要调用多个服务并操作多个数据库实现服务调用的分布式事务问题变的非常突出。分布式事务已经成为微服务落地最大的阻碍也是最具挑战性的一个技术难题。 1. 什么是微服务化带来的分布式事务问题 首先设想一个传统的单体应用Monolithic App通过 3 个 Module在同一个数据源上更新数据来完成一项业务。 很自然的整个业务过程的数据一致性由本地事务来保证。 随着业务需求和架构的变化单体应用被拆分为微服务原来的 3 个 Module 被拆分为 3 个独立的服务分别使用独立的数据源Pattern: Database per service。业务过程将由 3 个服务的调用来完成。 此时每一个服务内部的数据一致性仍有本地事务来保证。而整个业务层面的全局数据一致性要如何保障呢这就是微服务架构下面临的典型的分布式事务需求我们需要一个分布式事务的解决方案保障业务全局的数据一致性。 2. Fescar 的发展历程 阿里是国内最早一批进行应用分布式微服务化改造的企业所以很早就遇到微服务架构下的分布式事务问题。 2014 年阿里中间件团队发布 TXCTaobao Transaction Constructor为集团内应用提供分布式事务服务。 2016 年TXC 经过产品化改造以 GTSGlobal Transaction Service的身份登陆阿里云成为当时业界唯一一款云上分布式事务产品在阿云里的公有云、专有云解决方案中开始服务于众多外部客户。 2019 年起基于 TXC 和 GTS 的技术积累阿里中间件团队发起了开源项目 FescarFast EaSy Commit And Rollback, FESCAR和社区一起建设这个分布式事务解决方案。 TXC/GTS/Fescar 一脉相承为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。 2.1 设计初衷 高速增长的互联网时代快速试错的能力对业务来说是至关重要的 一方面不应该因为技术架构上的微服务化和分布式事务支持的引入给业务层面带来额外的研发负担。 另一方面引入分布式事务支持的业务应该基本保持在同一量级上的性能表现不能因为事务机制显著拖慢业务。 基于这两点我们设计之初的最重要的考量就在于 对业务无侵入这里的“侵入”是指因为分布式事务这个技术问题的制约要求应用在业务层面进行设计和改造。这种设计和改造往往会给应用带来很高的研发和维护成本。我们希望把分布式事务问题在 中间件 这个层次解决掉不要求应用在业务层面做额外的工作。 高性能引入分布式事务的保障必然会有额外的开销引起性能的下降。我们希望把分布式事务引入的性能损耗降到非常低的水平让应用不因为分布式事务的引入导致业务的可用性受影响。 2.2 既有的解决方案为什么不满足 既有的分布式事务解决方案按照对业务侵入性分为两类即对业务无侵入的和对业务有侵入的。 业务无侵入的方案 既有的主流分布式事务解决方案中对业务无侵入的只有基于 XA 的方案但应用 XA 方案存在 3 个方面的问题 要求数据库提供对 XA 的支持。如果遇到不支持 XA或支持得不好比如 MySQL 5.7 以前的版本的数据库则不能使用。 受协议本身的约束事务资源的锁定周期长。长周期的资源锁定从业务层面来看往往是不必要的而因为事务资源的管理器是数据库本身应用层无法插手。这样形成的局面就是基于 XA 的应用往往性能会比较差而且很难优化。 已经落地的基于 XA 的分布式解决方案都依托于重量级的应用服务器Tuxedo/WebLogic/WebSphere 等)这是不适用于微服务架构的。 侵入业务的方案 实际上最初分布式事务只有 XA 这个唯一方案。XA 是完备的但在实践过程中由于种种原因包含但不限于上面提到的 3 点往往不得不放弃转而从业务层面着手来解决分布式事务问题。比如 基于可靠消息的最终一致性方案 TCC Saga 都属于这一类。这些方案的具体机制在这里不做展开网上这方面的论述文章非常多。总之这些方案都要求在应用的业务层面把分布式事务技术约束考虑到设计中通常每一个服务都需要设计实现正向和反向的幂等接口。这样的设计约束往往会导致很高的研发和维护成本。 2.3 理想的方案应该是什么样子 不可否认侵入业务的分布式事务方案都经过大量实践验证能有效解决问题在各种行业的业务应用系统中起着重要作用。但回到原点来思考这些方案的采用实际上都是迫于无奈。设想如果基于 XA 的方案能够不那么重并且能保证业务的性能需求相信不会有人愿意把分布式事务问题拿到业务层面来解决。 一个理想的分布式事务解决方案应该像使用本地事务一样简单业务逻辑只关注业务层面的需求不需要考虑事务机制上的约束。 3. 原理和设计 我们要设计一个对业务无侵入的方案所以从业务无侵入的 XA 方案来思考是否可以在 XA 的基础上演进解决掉 XA 方案面临的问题呢 3.1 如何定义一个分布式事务 首先很自然的我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的 分支事务 达成一致要么一起成功提交要么一起失败回滚。此外通常分支事务本身就是一个满足 ACID 的本地事务。这是我们对分布式事务结构的基本认识与 XA 是一致的。 其次与 XA 的模型类似我们定义 3 个组件来协议分布式事务的处理过程。 Transaction Coordinator (TC)事务协调器维护全局事务的运行状态负责协调并驱动全局事务的提交或回滚。 Transaction Manager (TM)控制全局事务的边界负责开启一个全局事务并最终发起全局提交或全局回滚的决议。 Resource Manager (RM)控制分支事务负责分支注册、状态汇报并接收事务协调器的指令驱动分支本地事务的提交和回滚。 一个典型的分布式事务过程 TM 向 TC 申请开启一个全局事务全局事务创建成功并生成一个全局唯一的 XID。 XID 在微服务调用链路的上下文中传播。 RM 向 TC 注册分支事务将其纳入 XID 对应全局事务的管辖。 TM 向 TC 发起针对 XID 的全局提交或回滚决议。 TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。 至此Fescar 的协议机制总体上看与 XA 是一致的。 3.2 与 XA 的差别在什么地方 架构层次 XA 方案的 RM 实际上是在数据库层RM 本质上就是数据库自身通过提供支持 XA 的驱动程序来供应用使用。 而 Fescar 的 RM 是以二方包的形式作为中间件层部署在应用程序这一侧的不依赖与数据库本身对协议的支持当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。 这个设计剥离了分布式事务方案对数据库在 协议支持 上的要求。 两阶段提交 先来看一下 XA 的 2PC 过程。 无论 Phase2 的决议是 commit 还是 rollback事务性资源的锁都要保持到 Phase2 完成才释放。 设想一个正常运行的业务大概率是 90% 以上的事务最终应该是成功提交的我们是否可以在 Phase1 就将本地事务提交呢这样 90% 以上的情况下可以省去 Phase2 持锁的时间整体提高效率。 这个设计在绝大多数场景减少了事务持锁时间从而提高了事务的并发度。 当然你肯定会问Phase1 即提交的情况下Phase2 如何回滚呢 3.3 分支事务如何提交和回滚 首先应用需要使用 Fescar 的 JDBC 数据源代理也就是 Fescar 的 RM。 Phase1 Fescar 的 JDBC 数据源代理通过对业务 SQL 的解析把业务数据在更新前后的数据镜像组织成回滚日志利用本地事务 的 ACID 特性将业务数据的更新和回滚日志的写入在同一个 本地事务中提交。 这样可以保证任何提交的业务数据的更新一定有相应的回滚日志存在。 基于这样的机制分支的本地事务便可以在全局事务的 Phase1 提交马上释放本地事务锁定的资源。 Phase2 如果决议是全局提交此时分支事务此时已经完成提交不需要同步协调处理只需要异步清理回滚日志Phase2 可以非常快速地完成。 如果决议是全局回滚RM 收到协调器发来的回滚请求通过 XID 和 Branch ID 找到相应的回滚日志记录通过回滚记录生成反向的更新 SQL 并执行以完成分支的回滚。 3.4 事务传播机制 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不支持 3.5 隔离性 全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。 在数据库本地隔离级别读已提交或以上的前提下Fescar 设计了由事务协调器维护的 全局写排他锁来保证事务间的写隔离将全局事务默认定义在读未提交的隔离级别上。 我们对隔离级别的共识是绝大部分应用在 读已提交 的隔离级别下工作是没有问题的。而实际上这当中又有绝大多数的应用场景实际上工作在读未提交的隔离级别下同样没有问题。 在极端场景下应用如果需要达到全局的 读已提交Fescar 也提供了相应的机制来达到目的。默认Fescar 是工作在 读无提交 的隔离级别下保证绝大多数场景的高效性。 事务的 ACID 属性在 Fescar 中的体现是一个比较复杂的话题我们会有专门的文章来深入分析这里不做进一步展开。 4. 适用场景分析 前文所述的 Fescar 的核心原理中有一个重要前提分支事务中涉及的资源必须是支持ACID 事务的 关系型数据库。分支的提交和回滚机制都依赖于本地事务的保障。所以如果应用使用的数据库是不支持事务的或根本不是关系型数据库就不适用。 另外目前 Fescar 的实现还存在一些局限比如事务隔离级别最高支持到读已提交的水平SQL 的解析还不能涵盖全部的语法等。 为了覆盖 Fescar 原生机制暂时不能支持应用场景我们定义了另外一种工作模式。 上面介绍的 Fescar 原生工作模式称为 ATAutomatic Transaction模式这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MTManual Transaction模式这种模式下分支事务需要应用自己来定义业务本身及提交和回滚的逻辑。 4.1 分支的基本行为模式 作为全局事务一部分的分支事务除本身的业务逻辑外都包含 4 个与协调器交互的行为 分支注册在分支事务的数据操作进行之前需要向协调器注册把即将进行的分支事务数据操作纳入一个已经开启的全局事务的管理中去在分支注册成功后才可以进行数据操作。 状态上报在分支事务的数据操作完成后需要向事务协调器上报其执行结果。 分支提交响应协调器发出的分支事务提交的请求完成分支提交。 分支回滚响应协调器发出的分支事务回滚的请求完成分支回滚。 4.2 AT 模式分支的行为模式 业务逻辑不需要关注事务机制分支与全局事务的交互过程自动进行。 4.3 MT 模式分支的行为模式 业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分形成一个 MT 分支加入全局事务。 MT 模式一方面是 AT 模式的补充。另外更重要的价值在于通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。 4.4 混合模式 因为 AT 和 MT 模式的分支从根本上行为模式是一致的所以可以完全兼容即一个全局事务中可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的AT 模式可以支持的使用 AT 模式AT 模式暂时支持不了的用 MT 模式来替代。另外自然的MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起纳入同一个分布式事务的管理中。 4.5 应用场景的远景 回到我们设计的初衷一个理想的分布式事务解决方案是不应该侵入业务的。MT 模式是在 AT 模式暂时不能完全覆盖所有场景的情况下一个比较自然的补充方案。我们希望通过 AT 模式的不断演进增强逐步扩大所支持的场景MT 模式逐步收敛。未来我们会纳入对 XA 的原生支持用 XA 这种无侵入的方式来覆盖 AT 模式无法触达的场景。 5. 扩展点 5.1 微服务框架的支持 事务上下文在微服务间的传播需要根据微服务框架本身的机制订制最优的对应用层透明的解决方案。有兴趣在这方面共建的开发者可以参考内置的对 Dubbo 的支持方案来实现对其他微服务框架的支持。 5.2 所支持的数据库类型 因为 AT 涉及 SQL 的解析所以在不同类型的数据库上工作会有一些特定的适配。有兴趣在这方面共建的开发者可以参考内置的对 MySQL 的支持方案来实现对其他数据库的支持。 5.3 配置和服务注册发现 支持接入不同的配置和服务注册发现解决方案。比如Nacos、Eureka、ZooKeeper 等。 5.4 MT 模式的场景拓展 MT 模式的一个重要作用就是可以把非关系型数据库的资源通过 MT 模式分支的包装纳入到全局事务的管辖中来。比如Redis、HBase、RocketMQ 的事务消息等。有兴趣在这方面共建的开发者可以在这里贡献一系列相关生态的适配方案。 5.5 事务协调器的分布式高可用方案 针对不同场景支持不同的方式作为事务协调器 Server 端的高可用方案。比如针对事务状态的持久化可以是基于文件的实现方案也可以是基于数据库的实现方案集群间的状态同步可以是基于 RPC 通信的方案也可以是基于高可用 KV 存储的方案。 6. Roadmap 蓝图 绿色部分是已经开源发布出来的黄色 部分是将在后续版本中由阿里发布出来的蓝色部分是我们和社区共建生态部分 对不同数据库的支持开发者可以参考 MySQL 的实现。 对不同微服务框架的支持开发者可以参考 Dubbo 的实现。 对 MQ、NoSQL 的支持开发者可以参考 TCC 的实现。 配置和服务注册发现开发者通过少量的工作可以接入任何可以提供这类服务的框架。 当然非 蓝色 的部分也非常欢迎社区参与进来贡献更优的解决方案。 另外XA 作为分布式事务的标准是一个完备的分布式事务解决方案不可或缺的远景的规划中我们一定需要把 XA 的支持加入进来。 初步的版本规划 v0.1.0 微服务框架支持: Dubbo 数据库支持: MySQL 基于 Spring AOP 的 Annotation 事务协调器: 单机版本 v0.5.x 微服务框架支持: Spring Cloud MT 模式 支持 TCC 模式事务的适配 动态配置和服务发现 事务协调器: 高可用集群版本 v0.8.x Metrics 控制台: 监控/部署/升级/扩缩容 v1.0.0 General Availability: 生产环境适用 v1.5.x 数据库支持: Oracle/PostgreSQL/OceanBase 不依赖 Spring AOP 的 Annotation 热点数据的优化处理机制 RocketMQ 事务消息纳入全局事务管理 NoSQL 纳入全局事务管理的适配机制 支持 HBase 支持 Redis v2.0.0 支持 XA 当然项目迭代演进的过程我们最重视的是社区的声音路线图会和社区充分交流及时进行调整。 原文链接 本文为云栖社区原创内容未经允许不得转载。
