共计 3613 个字符，预计需要花费 10 分钟才能阅读完成。
本文将会比照 Seata 与 EasyTransaction 两个分布式事务的一些高层设计，置信大家会有播种。
Seata 的概述
Seata（曾用名 Fescar, 开源版本 GTS）是阿里的开源分布式事务框架，其 RoadMap 中指出了其心愿与社区单干从新构建出一个全面的分布式事务框架。
对于 Seata 的相干介绍能够看这里，本文不再赘述。尽管其后续路线有所调整，但整体实用。
https://github.com/seata/seat…
学习理解 Seata 后咱们能够比对着理解 EasyTransaction 的架构设计。
EasyTransaction 概述
EasyTransaction（后简称 ET）的指标也是构建出一个全面分布式事务解决方案，到目前为止其蕴含 TCC, 主动弥补（Seata AT），手动弥补，牢靠事务音讯、Saga 事务等等多种状态。
上面将就两个框架在设计上的差别进行剖析
外围差别图示
借用 Seata 的一张图：
与 Seata 不同，EasyTransaction 对应的图如下：
TC 差别
Seata:
有独立部署的集中式 TCRM、TM 与 TC 的交互通过 RPC 进行
TC 中能够看到每个具体的事务分支，对立协调所有事务分支的提交及回滚
EasyTransaction:
TC 是业务服务过程中的一个模块，并没有独立进去，且存在子事务的服务实例都会调用起 TC 模块如 ServiceA，B,C 都有 TC，但 ServiceD，E 没有这里的有无指代的是这一次事务里 TC 的性能有没有被触发 TC 与 TM,RM 的交互在过程内进行
每个 TC 只能协调其间接子事务如 ServiceA 的 TC 只晓得 ServiceB 及 ServiceE 的子事务但 ServiceB 晓得还有 ServiceC 的子事务，因而能够递归协调每个服务实例发动的全局事务，服务实例本身会先尝试一次自协调（大多数都能胜利），若自协调失败，则由一个服务实例兜底处理事务协调
Seata 有集中式的 TC，这样其能够 更容易 实现对分布式事务的监管控, 如对于 APM、Metrics、对立限流 等等性能。
但在 EasyTransaction 中的 TC 模式能够节约 TC 网络交互工夫，在上述 Seata 的业务图中，ET 的模式在两阶段提交中的第一阶段能节约 6 次 网络来回工夫 及 正反序列化工夫。
[（registerBranch 以及 reportBranch）* n 个调用层级]
在两阶段提交的第二阶段中，对立提交或者回滚过程中，Seata 的模式则是比 EasyTransaction 快，因为其不须要层级传递上来。视调用层级 N 的区别，ET 状态的第二阶段会比 Seata 慢 n-1 个网络来回及正反序列化的的工夫。
[(commit 或者 rollback) * (n-1)个调用层级]
(注：若思考 commit/rollback 的秩序的话，实际上 seata 要依照 业务产生程序顺次提交 或者 逆序回滚，其也为串行，这也为其默认做法，所以实际上 ET 在这个阶段也会比 Seata 快一个 网络来回及正反序列化的的工夫)
至于 因为数据分散性等等起因 APM、Metrics、对立限流 等等性能在 ET 模式如何实现 的这个问题，咱们能够参考一般的 RPC 是怎么做的，将其纳入对立的 RPC 治理即可，只是对立管控的力度没有集中式的弱小。
同时分散型的 TC 能 更容易 达到更高级别的可用性，其无需保障 TC 是否存活，业务服务在则 TC 在。扩散的特色也让压力能在失常业务状况下，能平均扩散到不同的业务实例当中。
TM 差别
Seata:
独立于 Spring/JTA 的 TransactionManager 独自创立了另外一套 TransactionManager
TransactionManager 在一个全局事务里只有一个
EasyTransaction:
扩大 Spring 的 PlatformTransactionManager（后称 PTM）的性能，使其能够管控分布式事务
在每个事务分支里都有 PTM（Spring 原生的事务），但存在子事务的 PTM 将会挂载扩大分布式事务相干解决以及启动 TC 模块性能
Seata 独自形象了一套 TM，其益处是自在可控，并能够不依赖于任何框架。
ET 其 TM 依赖于 Spring 的 PTM 的话，Spring 这个框架就变成了应用 ET 的必选项。但绝对的益处就是，所有作用于这个 PTM 的设施都能够作用于 EasyTransaction。
例如 Spring 的 RollbackFor，Transactional，Suspend 注解，XML 事务切面配置等等都能够间接为 EasyTransaction 所用。因为 ET 仅仅只是扩大，因而这些性能都能兼容。甚至于咱们要引入 JTA，EasyTransaction 也能兼容，因为 PTM 本身就有 JTA 的实现。
RM 差别
Seata:
所有参加到全局事务的 RM 都是平等的存在
EasyTransaction
存在主控 RM（发起方 RM、发起方事务）, 从事务 RM 的区别
Seata 全局事务里的 RM 都是平等的存在，整体逻辑上有简略对立的美，但因而其所有的 RM 都必须能承受两阶段的管控。
但在惯例的业务模式中，全局事务开始者（Seata 里带 TM 的那个）的事务，根本都能够在一阶段内获知全局事务应该回滚或者提交，但因为 Seata RM 都平等的模式，发起方 RM 必要要用 AT 模式（记录回滚数据），或者编写 TCC 的提交回滚办法，这里有一些额定的性能损耗
ET 模式里存在事务发起方 RM 的设定，其只有事务发起方的事务提交胜利则全局事务（最终）提交，发起方事务提交失败则全局事务（最终）回滚，因而其事务发起方无需兼容两阶段提交的协定，节约了相干的性能老本。当然，ET 的事务发起方 RM 也能够不写入任何业务，这样的话，就跟 Seata 的模式一样了。
主动弥补实现差别
Seata:
全局锁通过 TC 保留并实现
EasyTransaction:
全局锁通过本地业务数据库保留
Seata 通过 TC 保留全局记录锁引入了更多的复杂度，但其能自在管制锁的实现，能针对场景实现出效率更高的锁。
EasyTransction 革新 Seata 的主动弥补性能，将原有的近程 TC 依赖革新成了 EasyTransaction 的分布式 TC，并将全局锁实现革新到业务 DB 中。主动弥补的整体实现复杂度升高了，但性能可能有所降落（未经测试）。
不过 Seata 相干的实现也在进行中
RPC 接口
Seata
初期 Seata 试图维持其外围性能简洁，不波及任何业务档次 RPC 的内容前面整合蚂蚁的 TCC 后框架外围代码开始呈现 RPC 相干内容
裸露给用户的是 RPC 框架原生的接口
接口入参出参模式较为自在
EasyTransaction
RPC 是 EasyTransaction 的一部分，其可更改替换
间接裸露给用户应用的并非 RPC 框架，而是 ET 的相干接口，RPC 仅作为底层通信的反对
接口入参出参模式有限度
EasyTransaction 没有采纳惯例的做法，而是用本人的接口代替原 RPC 接口的一个起因是这样做能对整个事务过程能 更容易 地把控，其间接与业务交互，晓得这一次调用的后果须要马上返回还是能够稍后返回，晓得这一次调用是重试还是业务被动触发的，能够通过 sdk 被动设置 RPC 框架不进行重试，被动设置使其进行黏性会话以提高效率而不必用户额定独自配置
同时因为 RPC 是 ET 的一部分，因而幂等、cancel 悬挂等等繁琐反复的问题，能更容易地通过框架主动反对（曾经实现），但如果 Seata 保持目前轻量级做法的话，未来在实现相干性能时可能会更艰难。
当然对业务裸露了 ET 的接口也算是一种耦合的加强。
动静配置、服务发现、APM 等
Seata
通过被动配置对接
EasyTransaction
利用 Spring 等现有设施对接
ET 利用 Spring 现有的配置接口进行配置，因而只有相干配置核心对接了 Spring，EasyTransaction 就能应用。但 Seata 为了缩小对 Spring 的依赖，因而相干对接须要独自进行。
ET 的 TC 整合到业务服务中，因而 TC 相干的服务发现只有利用业务本身的服务发现就能实现。而 Seata 的 TC 独自部署，因而须要肯定的适配工作。
跟下面的起因相似，EasyTransaction 的 APM 等操作只需借用曾经整合到 RPC 框架的 APM 即可，而 Seata 须要肯定的适配工作
总结
Seata 在短短几个月内能积攒近万 Star 除了阿里的技术号召力外，当然还有另外一个起因是分布式事务畛域如此广泛且重要，但短少一个能让小白都能释怀无脑应用权威的实现，无疑 Seata 在如此热烈的社区反对下很有心愿能成为这么一个实现。
但在 Seata 真正成为这个权威实现前，我感觉大家也能够抽空理解下 EasyTransaction 这个目前性能更为弱小、代码更为稳固、已上过生产的实现~
当然以上内容很多都带集体主观偏见，心愿各位能补充各种认识，兼听则明！
如果本文对你有帮忙，别忘记给我个 3 连，点赞，转发，评论，
咱们下期见！答案获取形式：已赞 已评 已关~
学习更多 JAVA 常识与技巧，关注与私信博主（666）
