Fescar是阿里巴巴开源的分布式事务中间件，以高效并且对业务零侵入的方式，解决微服务场景下面临的分布式事务问题。
微服务化带来的分布式事务问题
假设传统的单体应用(Monolithic App)，通过3个Module，在同个数据源上更新数据来完成整个业务过程的数据一致性由本地事务来保证。
随着业务需求和架构的变化，单体应用被拆分为微服务：原来的3个Module被拆分为3个独立的服务，分别使用独立的数据源Pattern: Database per service，业务过程将由 3 个服务的调用来完成，如图所示：
此时，每个服务内部的数据一致性仍有本地事务来保证，而整个业务层面的全局数据一致性(分布式事务)要如何保障？
分布式事务的关注点
高速增长的互联网时代，快速试错的能力对业务来说是至关重要的，故分布式事务解决方案需要对业务无侵入，高性能。
业务无侵入的方案
既有的主流分布式事务解决方案中，对业务无侵入的只有基于 XA 的方案，但应用 XA 方案存在 3 个方面的问题：
要求数据库提供对 XA 的支持。如果遇到不支持 XA的数据库，则不能使用。
受协议本身的约束，事务资源的锁定周期长。长周期的资源锁定从业务层面来看，往往是不必要的，而因为事务资源的管理器是数据库本身，应用层无法插手。这样形成的局面就是，基于 XA 的应用往往性能会比较差，而且很难优化。
已经落地的基于 XA 的分布式解决方案，都依托于重量级的应用服务器（Tuxedo/WebLogic/WebSphere 等)，这是不适用于微服务架构的。
侵入业务的方案
基于可靠消息的最终一致性方案
TCC
Saga
在应用的业务层面把分布式事务技术约束考虑到设计中，通常每个服务都需要设计实现正向和反向的幂等接口。
理想的解决方案
理想的分布式事务解决方案应该像使用本地事务，业务逻辑只关注业务层面的需求，不需要考虑事务机制上的约束。
Fescar原理和设计
分布式事务的定义
分布式事务可理解成包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。通常分支事务本身是个满足ACID的本地事务。
与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是一致的。
Fescar与XA的差别
架构层次
XA方案的RM实际上是在数据库层，RM本质上就是数据库自身(通过提供支持 XA 的驱动程序来供应用使用)。而Fescar的RM是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持XA协议。这对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。
Fescar的设计剥离了分布式事务方案对数据库在协议支持上的要求。
两阶段提交
XA 的 2PC 过程。
无论Phase2的决议是commit还是rollback，事务性资源的锁都要保持到Phase2完成才释放。正常运行的业务在通常情况下，事务是成功提交的。故在Fescar中，在Phase1就将本地事务提交，省去Phase2持锁的时间，整体提高效率。
Fescar的设计，在绝大多数场景减少了事务持锁时间，从而提高了事务的并发度。
分支事务的提交和回滚
首先应用需要使用Fescar的JDBC数据源代理，也就是Fescar的RM。
Phase1：
Fescar的JDBC数据源代理通过对业务SQL的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务的ACID特性，将业务数据的更新和回滚日志的写入在同一个本地事务中提交。这样可以保证任何提交的业务数据的更新一定有相应的回滚日志存在。
基于这样的机制，分支的本地事务便可以在全局事务的Phase1提交，马上释放本地事务锁定的资源。
Phase2：
如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理(只需要异步清理回滚日志)，Phase2可以非常快速地完成。
如果决议是全局回滚，RM收到协调器发来的回滚请求，通过XID和Branch ID找到相应的回滚日志记录，通过回滚记录生成反向的更新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是工作在读无提交的隔离级别下，保证绝大多数场景的高效性。
适用场景分析
Fescar的核心原理中的重要前提：分支事务中涉及的资源，必须是支持ACID事务的关系型数据库。分支的提交和回滚机制，都依赖于本地事务的保障。当前Fescar的实现局限：事务隔离级别最高支持到读已提交的水平，SQL的解析还不能涵盖全部的语法等。为覆盖Fescar原生机制暂时不能支持应用场景，其定义了另外的工作模式。以上介绍的Fescar原生工作模式称为 Automatic Transaction【AT】模式，这种模式是对业务无侵入的。与之相应的另外一种工作模式称为MT【Manual Transaction】模式，这种模式下，分支事务需要应用自己来定义业务本身及提交和回滚的逻辑。
分支的基本行为模式
作为全局事务一部分的分支事务，除本身的业务逻辑外，都包含4个与协调器交互的行为：
分支注册：在分支事务的数据操作进行之前，需要向协调器注册，把即将进行的分支事务数据操作，纳入一个已经开启的全局事务的管理中去，在分支注册成功后，才可以进行数据操作。
状态上报：在分支事务的数据操作完成后，需要向事务协调器上报其执行结果。
分支提交：响应协调器发出的分支事务提交的请求，完成分支提交。
分支回滚：响应协调器发出的分支事务回滚的请求，完成分支回滚。
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模式无法触达的场景。
扩展点
微服务框架的支持
事务上下文在微服务间的传播需要根据微服务框架本身的机制，订制最优的，对应用层透明的解决方案。
所支持的数据库类型
因为AT涉及SQL的解析，所以在不同类型的数据库上工作，会有一些特定的适配。
配置和服务注册发现
支持接入不同的配置和服务注册发现解决方案。比如：Nacos、Eureka、ZooKeeper 等。
MT模式的场景拓展
MT模式的一个重要作用就是，可以把非关系型数据库的资源，通过MT模式分支的包装，纳入到全局事务的管辖中来。比如，Redis、HBase、RocketMQ的事务消息等。
事务协调器的分布式高可用方案
针对不同场景，支持不同的方式作为事务协调器Server端的高可用方案。比如针对事务状态的持久化，可以是基于文件的实现方案，也可以是基于数据库的实现方案；集群间的状态同步，可以是基于RPC通信的方案，也可以是基于高可用KV存储的方案。