内容简介：点击阅读原文，给分布式事务pack点个“☆”吧~
点击上方蓝字关注我们～:arrow_up::arrow_up::arrow_up:
概述
由于微服务架构大行其道，分布式通信几何级增加，必然带来一致性问题，也就是说，以前你遇到不一致的概率可能是100年1次，现在可能是1年1次，甚至1天1次。微服务架构的前期，大多数开发者只关注拆分，选择性忽略一致性、性能、可用性、 工具 链等问题，导致架构步履维艰，在这些问题当中，一致性是最容易被忽略的。当然，绝大多数场景并不需要那么高的一致性，可以采用失败重试的策略简单处理。 从目前业界的情况来看，主要有如下几种实现方式：
-
XA（2PC）
-
失败重试
-
可靠事件
-
Saga
-
TCC
实际上很多方案都要结合业务去做，但是事务保证本身是一个通用的技术，工程师更希望抽象出来，通过简单的配置、注解就能搞定，并且不会大幅降低性能。
下面就给大家介绍两个开源的关于分布式事务的明日之星框架。
对比
出身
Fescar是阿里巴巴开源的分布式事务中间件，基于其内部的TXC和GTS的技术积累。虽然此框架非常活跃，但是19年刚刚开源，目前0.3版本，如果用于生产环境风险较大。
servicecomb-pack出自华为微服务框架servicecomb，servicecomb在Apache已经毕业了，但是一直比较“低调”。知名数据库中间 Sharding-Sphere采用的就是 servicecomb-pack提供的saga方案 。
实现原理
fescar实际上本质就是将一个分布式事务转化为多个单库事务。
没错，这就是Saga的思想，所有的正向操作，都保留逆向操作。一旦要回滚，只需要执行逆向操作就可以了。
如图所示，这种方案和基于业务实现的原理比较像，就是在业务数据库中额外增加一张事件表，这个事件表就是关键所在，在更新正常业务数据库的同时，在一个单库事务内（同一个数据库连接）同步更新事件表，这样来保证不丢数据。我们可以回顾一下一致性的要求，“要么同时成功，要么同时失败。”单库事务就可以保证。
如图所示，business要去调用Storage和order服务，如何保证事务呢？bussiness是事务的发起者，也叫TM，Order、Storage是事务的执行者，是被调用的服务，也叫RM，TC负责整体协调，可以生成全局事务ID，所有被调用的服务就是通过这个全局的事务ID串联起来的，另外，TC承担分布式锁的能力，这个分布式锁主要是为了解决写隔离，拿到锁才有写的权利，当然TC必须是高可用的。Storage和Order在进行业务操作的时候除了正常存储业务数据，还要在同一个事务内实现事件表的更新，一旦出现回滚的要求，需要根据事件表生成逆向操作的SQL，并且执行回滚。
servicecomb-pack和fescar一样，同样是saga的思想，所有的正向操作，都保留逆向操作。一旦要回滚，只需要执行逆向操作就可以了。但是，除此之外，servicecomb-pack也支持TCC。
如图所示，Omega作为一个客户端，拦截所有的事务操作，事务开始向Alpha记录开始记录，事务结束向Alpha记录事务结束记录，一旦出现问题，直接在Alpha事件表中生成逆向操作，你应该已经看出来了，和fescar不同的是，事件表中的数据存储在全局协调者（alpha）这一侧。
两种做法各有优劣吧，存在业务侧实际上是有侵入的，不是绝对意义上的无侵入，虽然单库事务性能不错，但是事件表的所有操作都会影响正常业务，无法做到更好的隔离性。存在协调者一侧相对来说隔离性更好一些，但是这里会有概率产生不一致，例如，实际上业务操作已经完成了，数据库更新成功了，但是写事件日志可能会失败，这时候协调者会认为业务操作也失败了。
稳定性
servicecomb-pack略胜一筹。更早的项目。
隔离性
fescar略胜一筹。虽然并不完美，但是已有解决方案。fescar写隔离通过TC提供的分布式锁来实现，读隔离通过select for update实现，当然，servicecomb-pack同样可以通过select for update实现读隔离。
复杂度
servicecomb-pack略胜一筹。角色少，思路简单。业务侧，两个框架都可以通过简单的注解实现。
文档
fescar略胜一筹。
性能
没有实际测试，从原理上来讲，相差无几。
支持的数据库
fescar目前只支持mysql，servicecomb-pack的方案不区分数据库。
更详细的内容可以参考官方文档。
总结
虽然两个框架的目标都是让业务开发人员更简单，不用关心分布式事务的问题，但是在我看来，如果要使用，还是要搞清楚原理，除非对此问题非常敏感，否则，应该谨慎使用，能不用最好不用。 两个框架都在快速发展中，从实现思想上来讲非常相似，都是很好的解决方案，未来的情况主要看投入程度。
声明：由于两个框架都在前期快速发展的阶段，案例和资料都很少，本人无法保证所有观点的正确性，如有谬误，请不吝赐教。
参考：
https://github.com/apache/servicecomb-pack/blob/master/docs/design_zh.md
https://github.com/alibaba/fescar
点击阅读原文，给分布式事务pack点个“☆”吧~
以上所述就是小编给大家介绍的《分布式事务实现方案阿里巴巴fescar、华为servicecomb-pack对比分析》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Pattern Recognition and Machine Learning
Christopher Bishop / Springer / 2007-10-1 / USD 94.95
The dramatic growth in practical applications for machine learning over the last ten years has been accompanied by many important developments in the underlying algorithms and techniques. For example,......一起来看看 《Pattern Recognition and Machine Learning》 这本书的介绍吧!
CSS 压缩/解压工具
在线压缩/解压 CSS 代码
RGB HSV 转换
RGB HSV 互转工具