阿里终面：分布式事务原理
Posted JavaGuide
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了阿里终面：分布式事务原理相关的知识，希望对你有一定的参考价值。
本文提纲如下
前言 单数据源事务 & 多数据源事务 常见分布式事务解决方案 2.1. 分布式事务模型 2.2. 二将军问题和幂等性 2.3. 两阶段提交（2PC） & 三阶段提交（3PC）方案 2.4. TCC 方案 2.5. 事务状态表方案 2.6. 基于消息中间件的最终一致性事务方案 Seata in AT mode 的实现 3.1. Seata in AT mode 工作流程概述 3.2. Seata in AT mode 工作流程详述 结束语
这篇文章先介绍单机数据库事务的 ACID 特性，然后指出分布式场景下操作多数据源面临的困境，引出分布式系统中常用的分布式事务解决方案，这些解决方案可以保证业务代码在操作多个数据源的时候，能够像操作单个数据源一样，具备 ACID 特性。
文章在最后给出业界较为成熟的分布式事务框架——Seata 的 AT 模式全局事务的实现。
的业务涉及两个数据库：库存库（repo_db）和订单库（repo_db），也就是 g 购物业务是调用多数据源来组合而成的。作为一个面向消费者的系统，电商系统要保证购物业务的高度可靠性，这里的可靠性同样有 ACID 四种语义。但是一个数据库的本地事务机制仅仅对落到自己身上的查询操作（这里的查询是广义的，包括增删改查等）起作用，无法干涉对其他数据库的查询操作。所以，数据库自身提供的本地事务机制无法确保业务对多数据源全局操作的可靠性。
基于此，针对多数据源操作提出的分布式事务机制就出现了。
分布式事务也可以叫做全局事务。
例如电商系统中订单模块调用支付模块扣款的时候，如果网络故障导致二将军问题出现，扣款请求重复发送，产生的重复扣款结果显然是不能被接受的。因此要保证一次事务中的扣款请求无论被发送多少次，接收方有且只执行一次扣款动作，这种保证机制叫做接收方的幂等性。
TCC 的流程如下图所示：
这里有个关键问题，既然 TCC 是一种服务层面上的 2PC。它是如何解决 2PC 无法应对宕机问题的缺陷的呢？
答案是不断重试。
由于 try 操作锁住了全局事务涉及的所有资源，保证了业务操作的所有前置条件得到满足，因此无论是 confirm 阶段失败还是 cancel 阶段失败都能通过不断重试直至 confirm 或 cancel 成功（所谓成功就是所有的服务都对 confirm 或者 cancel 返回了 ACK）。
这里还有个关键问题，在不断重试 confirm 和 cancel 的过程中（考虑到网络二将军问题的存在）有可能重复进行了 confirm 或 cancel，因此还要再保证 confirm 和 cancel 操作具有幂等性，也就是整个全局事务中，每个参与者只进行一次 confirm 或者 cancel。实现 confirm 和 cancel 操作的幂等性，有很多解决方案，例如每个参与者可以维护一个去重表（可以利用数据库表实现也可以使用内存型 KV 组件实现），记录每个全局事务（以全局事务标记 XID 区分）是否进行过 confirm 或 cancel 操作，若已经进行过，则不再重复执行。
TCC 由支付宝团队提出，被广泛应用于金融系统中。我们用银行账户余额购买基金时，会注意到银行账户中用于购买基金的那部分余额首先会被冻结，由此我们可以猜想，这个过程大概就是 TCC 的第一阶段。
：上面第 2 步中 order-service 发送 repo_deduction_msg 消息失败，对于发送方 order-service 来说，可能是消息中间件没有收到消息；也可能是中间件收到了消息，但向发送方 order-service 响应的 ACK 由于网络故障没有被 order-service 收到。因此 order-service 贸然进行事务回滚，撤销“执行插入订单记录的查询语句”，是不对的，因为 repo-service 那边可能已经接收到 repo_deduction_msg 并成功进行了库存扣减，这样 order-service 和 repo-service 两方就产生了数据不一致问题。
以上是被误解的实现方式，下面给出正确的实现方式，如下所示：
上图所示的方案，利用消息中间件如 rabbitMQ 来实现分布式下单及库存扣减过程的最终一致性。对这幅图做以下说明：
1）order-service 中，
call 库存服务的扣减库存接口
call 订单服务的创建订单接口
commit global_trx
在库存服务的数据库中，存在如下的库存表 t_repo：
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10001 | 20001 | xx 键盘 | 98 | 200.0 |
| 10002 | 20002 | yy 鼠标 | 199 | 100.0 |
在订单服务的数据库中，存在如下的订单表 t_order：
| id | order_code | user_id | production_code | count | price |
|---|---|---|---|---|---|
| 30001 | 2020102500001 | 40001 | 20002 | 1 | 100.0 |
| 30002 | 2020102500001 | 40001 | 20001 | 2 | 400.0 |
现在，id 为 40002 的用户要购买一只商品代码为 20002 的鼠标，整个分布式事务的内容为：
1）在库存服务的库存表中将记录
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠标 | 199 | 100.0 |
修改为
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠标 | 198 | 100.0 |
2）在订单服务的订单表中添加一条记录
| id | order_code | user_id | production_code | count | price |
|---|---|---|---|---|---|
| 30003 | 2020102500002 | 40002 | 20002 | 1 | 100.0 |
以上操作，在 AT 模式的第一阶段的流程图如下：
从 AT 模式第一阶段的流程来看，分支的本地事务在第一阶段提交完成之后，就会释放掉本地事务锁定的本地记录。这是 AT 模式和 XA 最大的不同点，在 XA 事务的两阶段提交中，被锁定的记录直到第二阶段结束才会被释放。所以 AT 模式减少了锁记录的时间，从而提高了分布式事务的处理效率。
AT 模式之所以能够实现第一阶段完成就释放被锁定的记录，是因为 Seata 在每个服务的数据库中维护了一张 undo_log 表，其中记录了对 t_order / t_repo 进行操作前后记录的镜像数据，即便第二阶段发生异常，只需回放每个服务的 undo_log 中的相应记录即可实现全局回滚。
undo_log 的表结构：
| id | branch_id | xid | context | rollback_info | log_status | log_created | log_modified |
|---|---|---|---|---|---|---|---|
| …… | 分支事务 ID | 全局事务 ID | …… | 分支事务操作的记录在事务前后的记录镜像，即 beforeImage 和 afterImage | …… | …… | …… |
第一阶段结束之后，Seata 会接收到所有分支事务的提交状态，然后决定是提交全局事务还是回滚全局事务。
1）若所有分支事务本地提交均成功，则 Seata 决定全局提交。 Seata 将分支提交的消息发送给各个分支事务，各个分支事务收到分支提交消息后，会将消息放入一个缓冲队列，然后直接向 Seata 返回提交成功。之后，每个本地事务会慢慢处理分支提交消息，处理的方式为：删除相应分支事务的 undo_log 记录。之所以只需删除分支事务的 undo_log 记录，而不需要再做其他提交操作，是因为提交操作已经在第一阶段完成了（这也是 AT 和 XA 不同的地方）。这个过程如下图所示：
分支事务之所以能够直接返回成功给 Seata，是因为真正关键的提交操作在第一阶段已经完成了，清除 undo_log 日志只是收尾工作，即便清除失败了，也对整个分布式事务不产生实质影响。
2）若任一分支事务本地提交失败，则 Seata 决定全局回滚，将分支事务回滚消息发送给各个分支事务，由于在第一阶段各个服务的数据库上记录了 undo_log 记录，分支事务回滚操作只需根据 undo_log 记录进行补偿即可。全局事务的回滚流程如下图所示：
这里对图中的 2、3 步做进一步的说明：
事务具有 ACID 特性，全局事务解决方案也在尽量实现这四个特性。以上关于 Seata in AT mode 的描述很显然体现出了 AT 的原子性、一致性和持久性。下面着重描述一下 AT 如何保证多个全局事务的隔离性的。
在 AT 中，当多个全局事务操作同一张表时，通过全局锁来保证事务的隔离性。下面描述一下全局锁在读隔离和写隔离两个场景中的作用原理：
1）写隔离（若有全局事务在改/写/删记录，另一个全局事务对同一记录进行的改/写/删要被隔离起来，即写写互斥）：写隔离是为了在多个全局事务对同一张表的同一个字段进行更新操作时，避免一个全局事务在没有被提交成功之前所涉及的数据被其他全局事务修改。写隔离的基本原理是：在第一阶段本地事务（开启本地事务的时候，本地事务会对涉及到的记录加本地锁）提交之前，确保拿到全局锁。如果拿不到全局锁，就不能提交本地事务，并且不断尝试获取全局锁，直至超出重试次数，放弃获取全局锁，回滚本地事务，释放本地事务对记录加的本地锁。
假设有两个全局事务 gtrx_1 和 gtrx_2 在并发操作库存服务，意图扣减如下记录的库存数量：
| id | production_code | name | count | price |
|---|---|---|---|---|
| 10002 | 20002 | yy 鼠标 | 198 | 100.0 |
AT 实现写隔离过程的时序图如下：
图中，1、2、3、4 属于第一阶段，5 属于第二阶段。
在上图中 gtrx_1 和 gtrx_2 均成功提交，如果 gtrx_1 在第二阶段执行回滚操作，那么 gtrx_1 需要重新发起本地事务获取本地锁，然后根据 undo_log 对这个 id=10002 的记录进行补偿式回滚。此时 gtrx_2 仍在等待全局锁，且持有这个 id=10002 的记录的本地锁，因此 gtrx_1 会回滚失败（gtrx_1 回滚需要同时持有全局锁和对 id=10002 的记录加的本地锁），回滚失败的 gtrx_1 会一直重试回滚。直到旁边的 gtrx_2 获取全局锁的尝试次数超过阈值，gtrx_2 会放弃获取全局锁，发起本地回滚，本地回滚结束后，自然会释放掉对这个 id=10002 的记录加的本地锁。此时，gtrx_1 终于可以成功对这个 id=10002 的记录加上了本地锁，同时拿到了本地锁和全局锁的 gtrx_1 就可以成功回滚了。整个过程，全局锁始终在 gtrx_1 手中，并不会发生脏写的问题。整个过程的流程图如下所示：
2）读隔离（若有全局事务在改/写/删记录，另一个全局事务对同一记录的读取要被隔离起来，即读写互斥）：在数据库本地事务的隔离级别为读已提交、可重复读、串行化时（读未提交不起什么隔离作用，一般不使用），Seata AT 全局事务模型产生的隔离级别是读未提交，也就是说一个全局事务会看到另一个全局事务未全局提交的数据，产生脏读，从前文的第一阶段和第二阶段的流程图中也可以看出这一点。这在最终一致性的分布式事务模型中是可以接受的。
如果要求 AT 模型一定要实现读已提交的事务隔离级别，可以利用 Seata 的 SelectForUpdateExecutor 执行器对 SELECT FOR UPDATE 语句进行代理。SELECT FOR UPDATE 语句在执行时会申请全局锁，如果全局锁已经被其他全局事务占有，则回滚 SELECT FOR UPDATE 语句的执行，释放本地锁，并且重试 SELECT FOR UPDATE 语句。在这个过程中，查询请求会被阻塞，直到拿到全局锁（也就是要读取的记录被其他全局事务提交），读到已被全局事务提交的数据才返回。这个过程如下图所示：
XA 协议是 X/Open 提出的分布式事务处理标准。文中提到的 2PC、3PC、TCC、本地事务表、Seata in AT mode，无论哪一种，本质都是事务协调者协调各个事务参与者的本地事务的进度，使使所有本地事务共同提交或回滚，最终达成一种全局的 ACID 特性。在协调的过程中，协调者需要收集各个本地事务的当前状态，并根据这些状态发出下一阶段的操作指令。这个思想就是 XA 协议的要义，我们可以说这些事务模型遵守或大致遵守了 XA 协议。
基于消息中间件的最终一致性事务方案是互联网公司在高并发场景中探索出的一种创新型应用模式，利用 MQ 实现微服务之间的异步调用、解耦合和流量削峰，保证分布式数据记录的最终一致性。它显然不遵守 XA 协议。
对于某项技术，可能存在业界标准或协议，但实践者针对具体应用场景的需求或者出于简便的考虑，给出与标准不完全相符的实现，甚至完全不相符的实现，这在工程领域是一种常见的现象。TCC 方案如此、基于消息中间件的最终一致性事务方案如此、Seata in AT mode 模式也如此。而新的标准往往就在这些创新中产生。
你难道真的没有发现 2.6 节（基于消息中间件的最终一致性事务方案）给出的正确方案中存在的业务漏洞吗？请各位重新看下这张图，仔细品一品两个微服务的调用方向，把你的想法留在评论区吧 :-)
最近写的一些干货，每篇都很用心，欢迎各位小伙伴阅读/点赞/分享：
怒肝1.3w+字给学姐讲明白计算机专业大学四年到底该学什么？
要想代码写的好，这几款IDEA插件你离不了！
Spring Boot搭建的一个在线文件预览系统！支持ppt、doc等多种类型文件预览
Github Star全球唯一的国产程序员！Apache 顶级项目Commiter。
推荐一款IDEA神器！一键查看Java字节码以及其他类信息
安利一个IDEA骚操作:一键生成方法的序列图
大二逃课总结的1.2w字的计算机网络知识！扫盲！
不太喜欢“只要钱给够就行，我愿意加班”这句话
我是Guide哥，Java后端开发，会一点前端知识，喜欢烹饪，自由的少年。一个三观比主角还正的技术人。我们下期再见！
阿里巴巴分布式事务中间件 Fescar 原理介绍
Fescar 是 阿里巴巴 开源的 分布式事务中间件，以 高效 并且对业务 0 侵入 的方式，解决 微服务 场景下面临的分布式事务问题。
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 (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 全局提交时，全局锁马上可以释放。只有在决议全局回滚的情况下，全局锁 才被持有至分支的 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 的支持加入进来。
以上是关于阿里终面：分布式事务原理的主要内容，如果未能解决你的问题，请参考以下文章