精华内容
下载资源
问答
  • fescar-server-0.4.2.zip

    2020-02-13 22:05:39
    Seata(原名Fescar) 是阿里18年开源的分布式事务的框架。Fescar的开源对分布式事务框架领域影响很大。作为开源大户,Fescar来自阿里的GTS,经历了好几次双十一的考验,一经开源便颇受关注。后来Fescar改名为Seata。...
  • 主要介绍了详解Spring Boot微服务如何集成fescar解决分布式事务问题,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • 主要介绍了Springboot-dubbo-fescar 阿里分布式事务的实现方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • fescar

    2019-03-15 23:06:08
  • 广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为“Fescar”,希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解。 FESCAR on GitHub ...

    广为人知的阿里分布式事务解决方案:GTS(Global 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 年,阿里中间件团队发布 TXC(Taobao Transaction Constructor),为集团内应用提供分布式事务服务。

    2016 年,TXC 经过产品化改造,以 GTS(Global Transaction Service)的身份登陆阿里云,成为当时业界唯一一款云上分布式事务产品,在阿云里的公有云、专有云解决方案中,开始服务于众多外部客户。

    2019 年起,基于 TXC 和 GTS 的技术积累,阿里中间件团队发起了开源项目 Fescar(Fast & 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 ™:控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
    • Resource Manager (RM):控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。

    一个典型的分布式事务过程:

    1. TM 向 TC 申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的 XID。
    2. XID 在微服务调用链路的上下文中传播。
    3. RM 向 TC 注册分支事务,将其纳入 XID 对应全局事务的管辖。
    4. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
    5. 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 原生工作模式称为 AT(Automatic Transaction)模式,这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MT(Manual 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

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

    相关链接:

    GTS on Aliyun:
    https://help.aliyun.com/product/48444.html

    原文地址:阿里开源分布式事务解决方案 Fescar 全解析

    官方文档推荐:https://github.com/alibaba/fescar/wiki/Home_Chinese

    个人微信公众号:
    这里写图片描述

    作者:jiankunking 出处:http://blog.csdn.net/jiankunking

    展开全文
  • workshop专场微服务专场开发者动手实践营Fescar在微服务架构下分布式一致性的实践.pdf
  • 阿里巴巴近日开源了分布式事务中间件 fescar。GitHub地址是 https://github.com/alibaba/fescar。 官方中文文档:https://github.com/alibaba/fescar/wiki/Home_Chinese 但是现在中文文档连接都不对,打不开,不知...

    文章目录
    简介
    运行官方demo
    事务回滚原理简介
    简介
    阿里巴巴近日开源了分布式事务中间件 fescar。GitHub地址是 https://github.com/alibaba/fescar。
    官方中文文档:https://github.com/alibaba/fescar/wiki/Home_Chinese
    但是现在中文文档连接都不对,打不开,不知为何。

    阿里巴巴现在内部使用的版本是GTS,fescar是其开源社区版本,fescar是Fast & EaSy Commit And Rollback, FESCAR的简称。更多简介请参考

    fescar官方wiki。
    fescar架构简介参考: 阿里巴巴开源分布式事务解决方案 Fescar

    运行官方demo
    将https://github.com/alibaba/fescar克隆到本地IDEA,demo运行使用到的是examples和server。

    我这里使用的是0.1.1版本:

    运行程序首先需要配置数据库并且初始化SQL。
    1、修改以下三个配置文件的MySQL地址

    test module中的MySQL配置也改一下:

    另外由于我本地的MySQL是8.X版本,所以驱动要升级。

    我使用的JDK11,com.alibaba.fescar.tm.dubbo.impl.OrderServiceImpl有个BUG,运行时会报错,需要修改一下:

    最后执行以下SQL语句初始化表:

    DROP TABLE IF EXISTS `storage_tbl`;
    CREATE TABLE `storage_tbl` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `commodity_code` varchar(255) DEFAULT NULL,
      `count` int(11) DEFAULT 0,
      PRIMARY KEY (`id`),
      UNIQUE KEY (`commodity_code`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;


    DROP TABLE IF EXISTS `order_tbl`;
    CREATE TABLE `order_tbl` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `user_id` varchar(255) DEFAULT NULL,
      `commodity_code` varchar(255) DEFAULT NULL,
      `count` int(11) DEFAULT 0,
      `money` int(11) DEFAULT 0,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;


    DROP TABLE IF EXISTS `account_tbl`;
    CREATE TABLE `account_tbl` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `user_id` varchar(255) DEFAULT NULL,
      `money` int(11) DEFAULT 0,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    CREATE TABLE `undo_log` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT,
      `branch_id` bigint(20) NOT NULL,
      `xid` varchar(100) NOT NULL,
      `rollback_info` longblob NOT NULL,
      `log_status` int(11) NOT NULL,
      `log_created` datetime NOT NULL,
      `log_modified` datetime NOT NULL,
      `ext` varchar(100) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `idx_unionkey` (`xid`,`branch_id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    好了,准备工作做完。
    实例简述:
    该实例模拟一个下单功能,由businessService发起,首先扣减库存,然后创建订单。

    启动server项目的com.alibaba.fescar.server.Server的main方法;
    启动example项目的AccountServiceImpl、OrderServiceImpl、StorageServiceImpl三个类的main方法,也就是dubbo服务提供者;
    以上4个服务启动完成后,查看DB中的记录,会初始化account_tbl和storage_tbl两张表,插入一条记录(左侧的表)

    执行com.alibaba.fescar.tm.dubbo.impl.BusinessServiceImplmain方法。会发现执行报错,DB表数据没有变更。
    是因为在com.alibaba.fescar.tm.dubbo.impl.BusinessServiceImpl#purchase方法中存在模拟的异常,我们将其注释掉,再次执行:

    注释掉以后执行,可以发现没有报错,DB中的数据已经正确修改(参见上图的右侧三张表的数据)。

    至此demo运行成功。

    事务回滚原理简介
    根据 阿里巴巴开源分布式事务解决方案 Fescar 介绍的原理,简单看看其rollback的原理。后续专门分析一下fescar的源码。

    阿里巴巴开源分布式事务解决方案 Fescar 讲到它是优化了两阶段提交,减少锁的时间,利用本地事务真正提交事务,并且记录可用于回滚的日志,然后出错时根据日志回滚。

    TransactionalTemplate是核心入口类;

    /*
     *  Copyright 1999-2018 Alibaba Group Holding Ltd.
     *
     *  Licensed under the Apache License, Version 2.0 (the "License");
     *  you may not use this file except in compliance with the License.
     *  You may obtain a copy of the License at
     *
     *       http://www.apache.org/licenses/LICENSE-2.0
     *
     *  Unless required by applicable law or agreed to in writing, software
     *  distributed under the License is distributed on an "AS IS" BASIS,
     *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     *  See the License for the specific language governing permissions and
     *  limitations under the License.
     */

    package com.alibaba.fescar.tm.api;

    import com.alibaba.fescar.core.exception.TransactionException;

    /**
     * Template of executing business logic with a global transaction.
     */
    public class TransactionalTemplate {

        /**
         * Execute object.
         *
         * @param business the business
         * @return the object
         * @throws TransactionalExecutor.ExecutionException the execution exception
         */
        public Object execute(TransactionalExecutor business) throws TransactionalExecutor.ExecutionException {

            // 1. get or create a transaction
            //获取全局事务管理器
            GlobalTransaction tx = GlobalTransactionContext.getCurrentOrCreate();

            // 2. begin transaction  事务begin
            try {
                tx.begin(business.timeout(), business.name());

            } catch (TransactionException txe) {
                throw new TransactionalExecutor.ExecutionException(tx, txe,
                    TransactionalExecutor.Code.BeginFailure);

            }

            Object rs = null;
            try {

                // Do Your Business  执行我们具体的业务逻辑
                rs = business.execute();

            } catch (Throwable ex) {

                // 3. any business exception, rollback.  出错时回滚
                try {
                    tx.rollback();

                    // 3.1 Successfully rolled back
                    throw new TransactionalExecutor.ExecutionException(tx, TransactionalExecutor.Code.RollbackDone, ex);

                } catch (TransactionException txe) {
                    // 3.2 Failed to rollback
                    throw new TransactionalExecutor.ExecutionException(tx, txe,
                        TransactionalExecutor.Code.RollbackFailure, ex);

                }

            }

            // 4. everything is fine, commit.  事务提交
            try {
                tx.commit();

            } catch (TransactionException txe) {
                // 4.1 Failed to commit
                throw new TransactionalExecutor.ExecutionException(tx, txe,
                    TransactionalExecutor.Code.CommitFailure);

            }
            return rs;
        }

    }

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    事务提交有两种:

    public enum GlobalTransactionRole {

        /**
         * The Launcher.
         * 开启全局事务的发起者
         */
        // The one begins the current global transaction.
        Launcher,

        /**
         * The Participant.
         * 分支事务,也就是分布在各个系统中的本地事务
         */
        // The one just joins into a existing global transaction.
        Participant
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    通过代码可以看到,分支事务什么都不做,也就是直接提交本地事务。Launcher事务会进行全局事务的提交。

    记录回滚日志的关键代码com.alibaba.fescar.rm.datasource.undo.UndoLogManager#flushUndoLogs中的undoLogContent:

    public static void flushUndoLogs(ConnectionProxy cp) throws SQLException {
            assertDbSupport(cp.getDbType());

            ConnectionContext connectionContext = cp.getContext();
            String xid = connectionContext.getXid();
            long branchID = connectionContext.getBranchId();

            BranchUndoLog branchUndoLog = new BranchUndoLog();
            branchUndoLog.setXid(xid);
            branchUndoLog.setBranchId(branchID);
            branchUndoLog.setSqlUndoLogs(connectionContext.getUndoItems());

            String undoLogContent = UndoLogParserFactory.getInstance().encode(branchUndoLog);

            if (LOGGER.isDebugEnabled()) {
                LOGGER.debug("Flushing UNDO LOG: " + undoLogContent);
            }

            PreparedStatement pst = null;
            try {
                pst = cp.getTargetConnection().prepareStatement(INSERT_UNDO_LOG_SQL);
                pst.setLong(1, branchID);
                pst.setString(2, xid);
                pst.setBlob(3, BlobUtils.string2blob(undoLogContent));
                pst.executeUpdate();
            } catch (Exception e) {
                if (e instanceof SQLException) {
                    throw (SQLException) e;
                } else {
                    throw new SQLException(e);
                }
            } finally {
                if (pst != null) {
                    pst.close();
                }
            }

        }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    这里根据上面的实例,查看其中一条日志:

    {
        "branchId": 1890459,
        "sqlUndoLogs": [{
            "afterImage": {
                "rows": [{
                    "fields": [{
                        "keyType": "PrimaryKey",
                        "name": "ID",
                        "type": 4,
                        "value": 8
                    }, {
                        "keyType": "NULL",
                        "name": "MONEY",
                        "type": 4,
                        "value": 199
                    }]
                }],
                "tableName": "account_tbl"
            },
            "beforeImage": {
                "rows": [{
                    "fields": [{
                        "keyType": "PrimaryKey",
                        "name": "ID",
                        "type": 4,
                        "value": 8
                    }, {
                        "keyType": "NULL",
                        "name": "MONEY",
                        "type": 4,
                        "value": 599
                    }]
                }],
                "tableName": "account_tbl"
            },
            "sqlType": "UPDATE",
            "tableName": "account_tbl"
        }],
        "xid": "10.240.130.105:8091:1890457"
    }
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    可以看到,日志中记录了修改之前和之后的数据变化情况,也就是数据镜像,回滚时就是根据这个进行回滚的。

    由于现在fescar才刚刚开源,远没有达到商用,需要到1.0版本才可以线上使用。本文只是简单了解入门一下,后续在升级几个版本之后再详细的分析其源码。
     

    展开全文
  • Fescar 是 阿里巴巴 开源的 分布式事务中间件,以 高效 并且对业务 0 侵入 的方式,解决 微服务 场景下面临的分布式事务问题。 一、发展历程 阿里是国内最早一批进行应用分布式(微服务化)改造的企业,所以很早就...

    简介

    Fescar 是 阿里巴巴 开源的 分布式事务中间件,以 高效 并且对业务 0 侵入 的方式,解决 微服务 场景下面临的分布式事务问题。

    一、发展历程

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

    • TXC:淘宝事务构造器(Taobao Transaction Constructor)。 阿里巴巴中间件团队自2014年起启动该项目,以解决因应用程序架构从单体应用改为微服务而导致的分布式事务问题。
    • GTS:全局事务服务。 TXC 经过产品化改造,以 GTS(Global Transaction Service) 的身份登陆阿里云,成为当时业界唯一一款云上分布式事务产品,在阿云里的公有云、专有云解决方案中,开始服务于众多外部客户。
    • Fescar:2019 年起,基于 TXC 和 GTS 的技术积累,阿里中间件团队发起了开源项目 Fescar(Fast & EaSy Commit And Rollback, FESCAR),和社区一起建设这个分布式事务解决方案。TXC/GTS/Fescar 一脉相承,为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。
    • Seata:2019年4月,更名为Seata,并调整开源计划。目前只支持MySQL,慎用。还未提供1.0

    二、什么是微服务化带来的分布式事务问题?

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

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

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

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

     

    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 的方案能够不那么 重,并且能保证业务的性能需求,相信不会有人愿意把分布式事务问题拿到业务层面来解决。

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

    三、原理和设计

    我们要设计一个对业务无侵入的方案,所以从业务无侵入的 XA 方案来思考:

    是否可以在 XA 的基础上演进,解决掉 XA 方案面临的问题呢?

    3.1 如何定义一个分布式事务?

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

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

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

    一个典型的分布式事务过程:

    1. TM 向 TC 申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的 XID。
    2. XID 在微服务调用链路的上下文中传播。
    3. RM 向 TC 注册分支事务,将其纳入 XID 对应全局事务的管辖。
    4. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
    5. 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 全局提交时,全局锁马上可以释放。只有在决议全局回滚的情况下,全局锁 才被持有至分支的 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 中的体现是一个比较复杂的话题,我们会有专门的文章来深入分析,这里不做进一步展开。

    四、 适用场景分析

    前文所述的 Fescar 的核心原理中有一个 重要前提:分支事务中涉及的资源,必须 是支持 ACID 事务的 关系型数据库。分支的提交和回滚机制,都依赖于本地事务的保障。所以,如果应用使用的数据库是不支持事务的,或根本不是关系型数据库,就不适用。

    另外,目前 Fescar 的实现还存在一些局限,比如:事务隔离级别最高支持到 读已提交 的水平,SQL 的解析还不能涵盖全部的语法等。

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

    上面介绍的 Fescar 原生工作模式称为 AT(Automatic Transaction)模式,这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MT(Manual 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.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 存储的方案。

    六、Roadmap

    蓝图

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

    • 对不同数据库的支持,开发者可以参考 MySQL 的实现。
    • 对不同微服务框架的支持,开发者可以参考 Dubbo 的实现。
    • 对 MQ、NoSQL 的支持,开发者可以参考 TCC 的实现。
    • 配置和服务注册发现:开发者通过少量的工作可以接入任何可以提供这类服务的框架。
    • 当然,非 蓝色 的部分也非常欢迎社区参与进来,贡献更优的解决方案。
    • 另外,XA 作为分布式事务的标准,是一个完备的分布式事务解决方案不可或缺的,远景的规划中,我们一定需要把 XA 的支持加入进来。

    Seata开源版本规划

    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
    展开全文
  • 分布式系统Fescar

    2019-06-26 10:47:22
    Fescar 的发展历程 阿里是国内最早一批进行应用分布式(微服务化)改造的企业,所以很早就遇到微服务架构下的分布式事务问题。 2014 年,阿里中间件团队发布TXC(Taobao Transaction Constructor),为集团内应用...
  • Fescar 是阿里巴巴开源的分布式事务中间件,以高效并且对业务0 侵入的方式,解决微服务场景下面临的分布式事务问题。 1. 什么是微服务化带来的分布式事务问题? 首先,设想一个传统的单体应用(Monolithic App),...
  • Fescar原理

    2020-01-23 14:14:33
    Fescar原理 1、概述 fescar刚推出不久,没几天。看了github的Issues,有人问:可以直接商用吗? 作者的回复: image 我们也看一下fescard的历史: 阿里是国内最早一批进行应用分布式(微服务化)改造的企业,所以很...
  • 什么是Fescar FESCAR(Fast & Easy Commit And Rollback) 是一个用于微服务架构的分布式事务解决方案,它的特点是高性能且易于使用,旨在实现简单并快速的事务提交与回滚,由阿里开源。框架的具体架构...
  • 基于 Fescar 解决微服务架构下数据一致性的实践 Fescar 是一款开源的分布式事务解决方案,提供高性能和简单易用的分布式事务服务。 随着业务的快速发展,应用单体架构暴露出代码可维护性差,容错率低,测试难度大,...
  • 因为在现在的项目中用到了微服务,分布式...刚好一月份阿里开源了FESCAR框架,就想着把它集成到Spring Cloud项目里。 项目技术架构是SpringBoot +JPA +MySql 实现步骤如下 1.pom文件添加Fescar 依赖 <depe...
  • <bean id="accountDataSourceProxy" class="com.alibaba.fescar.rm.datasource.DataSourceProxy"> 说明: 上述配置来自example例子中的dubbo-account-service.xml文件。 上述核心在于创建了Druid...
  • 从零开始学Seata(Fescar)-简介

    千次阅读 2019-02-19 11:57:57
    Seata(Fescar)是阿里巴巴集团在2019年1月开源的分布式事务解决方案。 本篇文章主要参考了官方网站的github的README.md,并在对其翻译的基础上,进行了编辑。 本文所有图片均来自官网。 定义 Seata(Fescar)是...
  • 前言在SOA、微服务架构流行的...我所在的团队也遇到了这个问题,为解决这个问题上,团队采用的是阿里开源的分布式中间件Fescar的解决方案,并详细了解了Fescar内部的工作原理,解决在使用Fescar中间件过程中的一些疑...
  • 导完后,我们会看到三个子工程:fescar-samples-dubbo、fescar-samples-nacos和fescar-samples-springboot。本文只需要关注fescar-samples-dubbo工程就可以了。 接下来,我们需要修改一下数据源和分布式协调器...
  • fescar-server

    2019-03-12 16:09:58
    https://blog.csdn.net/kris1122/article/details/88395659 什么是Fescar? 一种分布式事务解决方案,具有高性能和易于使用的微服务架构。
  • 一般,数据库事务的隔离级别会被设置成 读已提交,已满足业务需求,这样对应在Fescar中的分支(本地)事务的隔离级别就是 读已提交,那么Fescar中对于全局事务的隔离级别又是什么呢?如果认真阅读了 分布式事务...
  • Fescar 简介 常见的分布式事务方式有基于 2PC 的 XA (e.g. atomikos),从业务层入手的 TCC( e.g. byteTCC)、事务消息 ( e.g. RocketMQ Half Message) 等等。XA 是需要本地数据库支持的分布式事务的协议,资源锁在...
  • FESCAR

    2019-10-07 23:11:28
    FESCAR:阿里重磅开源分布式事务解决方案 FESCAR名字的由来:Fast & EaSy Commit And Rollback FESCAR是啥? 被用在微服务架构中的高性能分布式事务解决方案。 微服务中的分布式事务问题 让我们想象一个...
  • fescar(Seata)详解

    2020-09-14 13:27:35
    广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为“Fescar”,希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解。 FESCAR on GitHub ...
  • 分布式事务--Fescar

    千次阅读 2019-01-19 20:37:31
    Fescar源码学习--事物管理者TM(服务调用方)》 《Fescar源码学习--资源管理者RM(服务提供方)》 《Fescar源码学习--服务协调器(TC)》 Fescar 是 阿里巴巴 开源的 分布式事务中间件,以 高效 并且对...
  • 一, Fescar Fescar是阿里巴巴开源的分布式事务中间件,以高效并且对业务0侵入的方式,解决微服务场景下面临的分布式事务问题。 二, 下载源码, 并导入IDE 源码下载 可以看到, fescar对dubbo的分布式事务支持, ...
  • Fescar-TM

    2019-03-11 19:26:19
    上一篇 Fescar 分布式事物中间件,学习了fescar 的前世今生及设计原理,接下来几篇来学习一下Fescar 中的三个非常重要的组件TM、RM、TC。 1、模型 再看下fescar 对 三者的定义吧,一个简单的模型, Transaction...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,753
精华内容 701
关键字:

fescar