内容简介：点击阅读原文，给分布式事务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对比分析》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 分布式文件系统架构对比
- 5种分布式锁实现的对比？
- 分布式追踪系统的对比、实现与使用—NodeTracing
- 对比各类分布式锁缺陷，抓住Redis分布式锁实现命门
- 5 大分布式 ID 生成器优缺点简单对比
- 对比Flink与Storm性能，分布式实时计算框架该这样选
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
XSS跨站脚本攻击剖析与防御
邱永华 / 人民邮电出版社 / 2013-9-1 / 49.00元
《XSS跨站脚本攻击剖析与防御》是一本专门剖析XSS安全的专业书，总共8章，主要包括的内容如下。第1章 XSS初探，主要阐述了XSS的基础知识，包括XSS的攻击原理和危害。第2章 XSS利用方式，就当前比较流行的XSS利用方式做了深入的剖析，这些攻击往往基于客户端，从挂马、窃取Cookies、会话劫持到钓鱼欺骗，各种攻击都不容忽视。第3章 XSS测试和利用工具，介绍了一些常见的XSS测试工具。第4......一起来看看 《XSS跨站脚本攻击剖析与防御》 这本书的介绍吧!
