分布式事务实现方案阿里巴巴fescar、华为servicecomb-pack对比分析

概述

由于微服务架构大行其道,分布式通信几何级增加,必然带来一致性问题,也就是说,以前你遇到不一致的概率可能是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的思想,所有的正向操作,都保留逆向操作。一旦要回滚,只需要执行逆向操作就可以了。

 

分布式事务实现方案阿里巴巴fescar、华为servicecomb-pack对比分析_第1张图片

如图所示,这种方案和基于业务实现的原理比较像,就是在业务数据库中额外增加一张事件表,这个事件表就是关键所在,在更新正常业务数据库的同时,在一个单库事务内(同一个数据库连接)同步更新事件表,这样来保证不丢数据。我们可以回顾一下一致性的要求,“要么同时成功,要么同时失败。”单库事务就可以保证。

 

分布式事务实现方案阿里巴巴fescar、华为servicecomb-pack对比分析_第2张图片

如图所示,business要去调用Storage和order服务,如何保证事务呢?bussiness是事务的发起者,也叫TM,Order、Storage是事务的执行者,是被调用的服务,也叫RM,TC负责整体协调,可以生成全局事务ID,所有被调用的服务就是通过这个全局的事务ID串联起来的,另外,TC承担分布式锁的能力,这个分布式锁主要是为了解决写隔离,拿到锁才有写的权利,当然TC必须是高可用的。Storage和Order在进行业务操作的时候除了正常存储业务数据,还要在同一个事务内实现事件表的更新,一旦出现回滚的要求,需要根据事件表生成逆向操作的SQL,并且执行回滚。

servicecomb-pack和fescar一样,同样是saga的思想,所有的正向操作,都保留逆向操作。一旦要回滚,只需要执行逆向操作就可以了。但是,除此之外,servicecomb-pack也支持TCC。

分布式事务实现方案阿里巴巴fescar、华为servicecomb-pack对比分析_第3张图片

如图所示,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

你可能感兴趣的:(java,cloud,架构)