一、由来
这个框架是结合齐牛金融公司之前遇到的分布式事务场景以及 支付宝程立分享的一个PPT<大规模SOA系统的分布式事务处理>而设计实现，意在解决之前公司对于每个分布式事务场景中都自行重复设计中间状态、幂等实现及重试逻辑的状况。采纳本框架后能解决现有已发现的所有分布式事务场景，减少设计开发设计工作量，提高开发效率，并统一保证事务实现的可靠性。
二、分布式事务场景及框架对应实现
分布式事务场景
无需分布式事务
最常用
最优先使用
使用消息队列完成的最终一致性事务
适用于业务主逻辑无需外部数据变更协助来完成的最终一致性事务
常见
若一定要与其他服务写接口发生交互，则优先使用
依据是否保证投递到订阅者，分为可靠消息及最大努力交付消息
有时业务需求一些本质是异步操作，但是尽可能同步返回结果，这本质也归属于这一类，但介于其有返回值，同步时可返回结果，其有区别于可靠消息。
使用传统补偿完成的最终一致性事务
适用于需要获知远程执行结果来决定逻辑事务走向 且 可以进行补偿的业务
次常见
若使用消息队列不能解决的事务问题优先考虑使用基于补偿的最终一致性事务
使用TCC完成最终一致性事务
适用于需要获知远程执行结果来决定逻辑事务走向 且 不可以进行补偿的业务
最不常见
最终解决办法，囊括所有必须使用2PC实现的场景。编码量最大，性能消耗最大，应尽量避免使用本类型的事务
框架对应实现及基本原理
框架实现了上述所有事物场景的解决方案，并提供了统一易用的接口。以下介绍基本实现原理
无需分布式事务
对于此类事务，框架完全不介入，不执行一行额外代码
其他事务场景
框架的核心依赖是Spring的TransactionSynchronization，只要使用的事务管理器继承自AbstractPlatformTransactionManager都能使用本框架（基本上都集成自本实现）。
对于分布式事务，框架会在调用远程事务方法后，将对应的框架操作挂载到TransactionSynchronization中，如：
使用消息队列完成的最终一致性事务，框架将会在事务COMMIT后发发送消息，保证只有COMMIT后事务才能被外部看见，这里也省去业务开发者对于 发送-确认-检测 类型 队列实现的代码量
使用TCC完成最终一致性事务,框架将会根据事务的实际完成情况调用Confirm或者Cancel,用传统补偿完成的最终一致性事务也类似
框架有后台线程负责CRASH恢复，其根据“在执行分布式服务调用前写入的WriteAheadLog获得可能已经调用的业务”以及“跟随业务一起提交的一条框架记录以确认的业务最终提交状态”来进行最终的CRASH具体操作（如TCC的Confirm或者Rollback）
框架对于幂等也有完整的实现（可选），框架能保证业务方法逻辑上只执行一遍（有可能执行多遍，但多次执行的方法会被回滚掉，因此，涉及不可回滚的外部资源时，业务程序需自行把控其幂等性）
框架对于方法间有调用关系依赖的也进行妥善的处理，例如基于传统补偿完成的最终一致性事务中
业务方法没有被调用，那么补偿方法对应的业务实现也不会被调用（但框架仍会记录下补偿方法已经被调用过）
补偿方法已经被掉用过了，那么业务方法无论曾经有没有被执行过，都不会被调用
所有远程调用的结果都是以Future形式返回，这给框架的性能优化提供了空间，在第一次获取结果前，所有的日志都不会被写入所有远程方法都不会被调用。一旦业务程序尝试获取执行结果时，才会批量写入日志及后续并发调用远程方法。
如果业务程序没有尝试获取执行结果，框架COMMIT前会统一尝试GET一遍，对于所有远程方法一旦抛出了Exception,框架都会在最后commit前将业务回滚，而无论之前是否catch住了，这样能保证编程模型的简洁，方便写出正确易理解的代码。
-
分布式事物框架Easy-Transaction--使用入门介绍 The origin This framework is inspired by a PPT (<大规模SOA系统的分布式事务处理>) written by Cheng Li who works in Alipay This framework aims to solve the problem in our company
-
分布式事物框架--EasyTransaction的入门介绍 柔性事务，分布式事务，TCC，SAGA，可靠消息，最大努力交付消息，事务消息，补偿，全局事务，soft transaction, distribute transaction, compensation ，本框架可一站式解决分布式SOA（包括微服务等）的事务问题。 一、由来 及 特性 这个框架是结合公司之前遇到的分布式事务场景
-
EasyTransaction是一个全功能的分布式事务框架，以下特性摘抄自其首页：https://github.com/QNJR-GROUP/EasyTransaction 一个框架包含多种事务形态，一个框架搞定所有类型的事务 多种事务形态可混合使用 高性能,大多数业务系统瓶颈在业务数据库，若不启用框架的幂等功能，对业务数据库的额外消耗仅为写入25字节的一行 可选的框架自带幂等实现及调用错乱次序处
-
2020博客地址汇总 2019年博客汇总 Seata EasyTransaction hmily Hmily是由碧桂园工程师开发，高性能异步分布式事务TCC框架。 Github地址：https://github.com/yu199195/hmily bytetcc Bytetcc是由北京新奥集团工程师开发，是一个兼容JTA规范的基于TCC机制的分布式事务管理器。目前开发到了第五版，稳定版本为第五版
-
QNJR-GROUP/EasyTransaction: 依赖于Spring的一个柔性事务实现，包含 TCC事务，补偿事务，基于消息的最终一致性事务，基于消息的最大努力交付事务交付 大规模SOA系统的分布式事务处理
-
Seata，阿里开源的这个框架貌似很好用，慢慢学习 EasyTransaction目前 功能更为强大、代码相对稳定、已上过生产的实现
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo
-
主要内容：1.2PC,2.三阶段提交(3PC),3.补偿事务（TCC）,4.本地消息表,5.消息事务,6.最大努力通知,7.Sagas 事务模型1.2PC 两阶段提交 mysql是通过日志系统完成事务的。就是两阶段提交:undolog和binlog的两阶段提交。 两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交。 第一阶段:投票阶段 1.协调者写命令进写入日志 2.协调者发一个prepare
-
再前不久，我写了一篇关于分布式事务中间件Fescar的解析，没过几天Fescar团队对其进行了品牌升级，取名为Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的Fescar的英文全称为Fast & EaSy Commit And Rollback。可以看见Fescar从名字上来看更加局限于Commit和Rollback
-
本文向大家介绍详解Spring Boot微服务如何集成fescar解决分布式事务问题，包括了详解Spring Boot微服务如何集成fescar解决分布式事务问题的使用技巧和注意事项，需要的朋友参考一下 什么是fescar? 关于fescar的详细介绍，请参阅fescar wiki。 传统的2PC提交协议，会持有一个全局性的锁，所有局部事务预提交成功后一起提交，或有一个局部事务预提交失败后一起回滚