注：该项目已更名为 Seata
FESCAR（Fast & Easy Commit And Rollback） 是一个用于微服务架构的分布式事务解决方案，它的特点是高性能且易于使用，旨在实现简单并快速的事务提交与回滚。
微服务架构中的分布式事务问题
从传统的单体应用说起，假设一个单体应用的业务由 3 个模块构成，三者使用单个本地数据源。
这样的话本地事务很自然就可以保证数据一致性。
但是在微服务架构中就不这么简单了，这 3 个模块被设计为 3 个不同数据源之上的 3 个服务，每个服务对应一个数据库。
本地事务当然也可以保证每个服务中的数据一致性，但是扩展到整个应用、整个业务逻辑范围来看，情况如何呢？
FESCAR 机制
FESCAR 就是用于解决上述微服务架构中的事务问题的解决方案。
如下图所示，分布式事务是一个全局事务（Global Transaction），由一批分支事务（Branch Transation）组成，通常分支事务只是本地事务。
FESCAR 中有三大基本组件：
-
Transaction Coordinator(TC)：维护全局和分支事务的状态，驱动全局事务提交与回滚。
-
Transaction Manager(TM)：定义全局事务的范围：开始、提交或回滚全局事务。
-
Resource Manager(RM)：管理分支事务处理的资源，与 TC 通信以注册分支事务并报告分支事务的状态，并驱动分支事务提交或回滚。
FESCAR 管理分布式事务的典型生命周期：
-
TM 要求 TC 开始新的全局事务，TC 生成表示全局事务的 XID。
-
XID 通过微服务的调用链传播。
-
RM 在 TC 中将本地事务注册为 XID 的相应全局事务的分支。
-
TM 要求 TC 提交或回滚 XID 的相应全局事务。
-
TC 驱动 XID 的相应全局事务下的所有分支事务，完成分支提交或回滚。
演进历史
-
TXC：Taobao Transaction Constructor，阿里巴巴中间件团队自 2014 年起启动该项目，以满足应用程序架构从单一服务变为微服务所导致的分布式事务问题。
-
GTS：Global Transaction Service，2016 年 TXC 作为阿里中间件的产品，更名为 GTS 发布。
-
FESCAR：2019 年开始基于 TXC/GTS 开源 FESCAR。
-
一、Fescar简介 Fescar是阿里巴巴开源的分布式事务中间件，以高效并且对业务0侵入的方式，解决微服务场景下面临的分布式事务问题。 官方介绍：https://github.com/seata/seata/wiki/%E6%A6%82%E8%A7%88 二、设计思路 通过API调用服务A，服务A中先对数据库A进行插入操作，然后通过feign调用服务B，在服务B中对数据库B进行插入操作，调用服务
-
Fescar原理 1、概述 fescar刚推出不久，没几天。看了github的Issues，有人问：可以直接商用吗？ 作者的回复： image 我们也看一下fescard的历史： 阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。 2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用
-
本文向大家介绍详解Spring Boot微服务如何集成fescar解决分布式事务问题，包括了详解Spring Boot微服务如何集成fescar解决分布式事务问题的使用技巧和注意事项，需要的朋友参考一下 什么是fescar? 关于fescar的详细介绍，请参阅fescar wiki。 传统的2PC提交协议，会持有一个全局性的锁，所有局部事务预提交成功后一起提交，或有一个局部事务预提交失败后一起回滚
-
我有两个微服务和调用来更新数据，然后插入另一个数据，但让我们考虑一下 失败，然后我们需要回滚由 更新的数据，否则我们将处于不一致的状态。 我也经历了佐贺patterns.will它满足了这种矛盾 谁能为此提出更好的解决方案？
-
最近在学微服务的分布式事务，不太明白为什么在微服务这种分布式系统中，原有的单体acid会出现问题 希望大佬们可以讲一下原理和思想
-
fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前， 已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如 LCN 的2pc型无侵入事务， 目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现 hmily tcc-transaction
-
针对Fescar 相信很多开发者已经对他并不陌生，当然Fescar 已经成为了过去时，为什么说它是过去时，因为Fescar 已经华丽的变身为Seata。如果还不知道Seata 的朋友，请登录下面网址查看。 SEATA GITHUB:[https://github.com/seata/seata] 对于阿里各位同学的前仆后继，给我们广大开发者带来很多开源软件，在这里对他们表示真挚的感谢与问候。 今天
-
主要内容：1.2PC,2.三阶段提交(3PC),3.补偿事务（TCC）,4.本地消息表,5.消息事务,6.最大努力通知,7.Sagas 事务模型1.2PC 两阶段提交 mysql是通过日志系统完成事务的。就是两阶段提交:undolog和binlog的两阶段提交。 两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交。 第一阶段:投票阶段 1.协调者写命令进写入日志 2.协调者发一个prepare
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
我知道最好使用 Saga 模式，但想想还是很有趣的： < Li > 2PC/XA分布式事务是否提供了仅从一个应用程序和一个TM与多个RM进行事务的可能性？ < li >如果没有-如果每个微服务只能访问自己的数据库，如何在多个微服务之间使用2PC/XA分布式事务来提供使用2PC的能力？我很乐意看到一个例子 < li >我们是否需要将TransactionManager服务作为一个独立的微服务，在多个