本篇文章给大家带来的内容是关于fescar分布式事务的介绍（图文），有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。 内容来自samhan
1、fescar分布式事务（概览） 内容来自zvvq
1.1. 概述 内容来自samhan666
Fescar 是 阿里巴巴 开源的 分布式事务中间件，以 高效 并且对业务0 侵入 的方式，解决 微服务 场景下面临的分布式事务问题。
zvvq.cn
1.2. Fescar 的发展历程 zvvq
2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。
内容来自zvvq，别采集哟
2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service） 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品 ，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。
2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。 zvvq
1.3. 设计初衷 copyright zvvq
对业务无侵入
zvvq
高性能 内容来自zvvq，别采集哟
1.4. 原理和设计 内容来自zvvq，别采集哟
1.4.1. 设计概念图 内容来自zvvq
内容来自samhan666
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
zvvq.cn
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
1.4.2. 与 XA 的差别在什么地方？
内容来自zvvq，别采集哟
XA 方案的 RM 实际上是在数据库层 ，RM 本质上就是数据库自身（通过提供支持 XA 的驱动程序来供应用使用）。 内容来自zvvq，别采集哟
而 Fescar 的 RM 是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。 zvvq
这个设计，剥离了分布式事务方案对数据库在 协议支持 上的要求
zvvq
1.4.3. 两阶段提交
1.4.3.1. XA 的 2PC 过程XA 的 2PC 过程 内容来自zvvq，别采集哟
无论 Phase2 的决议是 commit 还是 rollback，事务性资源的锁都要保持到 Phase2 完成才释放。 内容来自zvvq，别采集哟
设想一个正常运行的业务，大概率是 90% 以上的事务最终应该是成功提交的，我们是否可以在 Phase1 就将本地事务提交呢？这样 90% 以上的情况下，可以省去 Phase2 持锁的时间，整体提高效率。 1.4.3.2. fescar的 2PC 过程
zvvq
分支事务中数据的 本地锁 由本地事务管理，在分支事务 Phase1 结束时释放。 内容来自samhan
同时，随着本地事务结束，连接 也得以释放。
分支事务中数据的 全局锁 在事务协调器侧管理，在决议 Phase2 全局提交时，全局锁马上可以释放。只有在决议全局回滚的情况下，全局锁 才被持有至分支的 Phase2 结束。
这个设计，极大地减少了分支事务对资源（数据和连接）的锁定时间，给整体并发和吞吐的提升提供了基础。
zvvq好，好zvvq
1.4.4. 分支事务如何提交和回滚？（重点）
首先，应用需要使用 Fescar 的 JDBC 数据源代理
zvvq.cn
，也就是 Fescar 的 RM 本文来自zvvq
Fescar 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。 内容来自zvvq，别采集哟
这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志
存在 内容来自samhan666
如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），Phase2 可以非常快速地完成。 本文来自zvvq
如果决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
内容来自samhan666
1.4.5. 事务传播机制
XID 是一个全局事务的唯一标识，事务传播机制要做的就是把 XID 在服务调用链路中传递下去，并绑定到服务的事务上下文中，这样，服务链路中的数据库更新操作，就都会向该 XID 代表的全局事务注册分支，纳入同一个全局事务的管辖。
基于这个机制，Fescar 是可以支持任何微服务 RPC 框架的。只要在特定框架中找到可以透明传播 XID 的机制即可，比如，Dubbo 的 Filter + RpcContext。 zvvq.cn
1.4.6. 分支的基本行为模式
作为全局事务一部分的分支事务，除本身的业务逻辑外，都包含 4 个与协调器交互的行为： zvvq好，好zvvq
分支注册： 在分支事务的数据操作进行之前，需要向协调器注册，把即将进行的分支事务数据操作，纳入一个已经开启的全局事务的管理中去，在分支注册成功后，才可以进行数据操作。 内容来自zvvq，别采集哟
状态上报： 在分支事务的数据操作完成后，需要向事务协调器上报其执行结果。
内容来自zvvq
分支提交：响应协调器发出的分支事务提交的请求，完成分支提交。
分支回滚：响应协调器发出的分支事务回滚的请求，完成分支回滚。
1.4.7. AT 模式分支的行为模式
业务逻辑不需要关注事务机制，分支与全局事务的交互过程自动进行 内容来自samhan666
1.4.8. MT 模式分支的行为模式
业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分，形成一个 MT 分支，加入全局事务。 copyright zvvq
1.4.9. 混合模式
因为 AT 和 MT 模式的分支从根本上行为模式是一致的，所以可以完全兼容，即，一个全局事务中，可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的：AT 模式可以支持的，使用 AT 模式；AT 模式暂时支持不了的，用 MT 模式来替代。另外，自然的，MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起，纳入同一个分布式事务的管理中。
内容来自zvvq
1.5. 初步的版本规划
v0.1.0
copyright zvvq
微服务框架支持: Dubbo
copyright zvvq
数据库支持: MySQL zvvq
基于 Spring AOP 的 Annotation 内容来自samhan666
事务协调器: 单机版本
内容来自samhan
v0.5.x
微服务框架支持: Spring Cloud
内容来自zvvq，别采集哟
MT 模式 内容来自samhan666
支持 TCC 模式事务的适配
动态配置和服务发现 内容来自samhan
事务协调器: 高可用集群版本
v0.8.x 内容来自zvvq，别采集哟
Metrics zvvq
控制台: 监控/部署/升级/扩缩容
内容来自samhan
v1.0.0 内容来自zvvq
General Availability: 生产环境适用
内容来自zvvq
v1.5.x zvvq好，好zvvq
数据库支持: Oracle/PostgreSQL/OceanBase copyright zvvq
不依赖 Spring AOP 的 Annotation
本文来自zvvq
热点数据的优化处理机制
本文来自zvvq
RocketMQ 事务消息纳入全局事务管理
copyright zvvq
NoSQL 纳入全局事务管理的适配机制
zvvq
支持 HBase
zvvq
支持 Redis
内容来自samhan
v2.0.0 内容来自samhan
支持 XA
copyright zvvq
当然，项目迭代演进的过程，我们最重视的是社区的声音，路线图会和社区充分交流及时进行调整。1.6. 总结 zvvq
看完概览，我一口鲜血喷出来，明明说好的支持任何微服务RPC框架，我现在要在适合SpringCloud的分布式事务解决方案中挑选个，你告诉我预计下下下下个版本会集成SpringCloud，路过的大神，推荐个吧
内容来自samhan
1.7. github开源地址
https://github.com/alibaba/fescar/ zvvq好，好zvvq
以上就是fescar分布式事务的详细介绍（图文）的详细内容，更多请关注其它相关文章！
zvvq