GTS-阿里巴巴全新分布式事务解决方案-阿里云开发者社区

开发者社区> 数据库> 正文

GTS-阿里巴巴全新分布式事务解决方案

简介: 事物问题是很多开发者和设计者非常头疼的问题,本文主要介绍阿里巴巴GTS-全新的分布式事务解决方案的思路。GTS提供完整的事务解决方案,可以解决跨数据库事务问题,微服务化的事务问题,消息事务问题和混合事务问题,同时保证业务的一致性。
事物问题是很多开发者和设计者非常头疼的问题,本文主要介绍阿里巴巴GTS-全新的分布式事务解决方案的思路。GTS提供完整的事务解决方案,可以解决跨数据库事务问题,微服务化的事务问题,消息事务问题和混合事务问题,同时保证业务的一致性。GTS对应用的侵入性非常低,性能非常强,GTS性能是传统的分布式事务的10倍,4c8g集群可达1.5万TPS,目前最高可达10万TPS。

演讲嘉宾简介:
厉启鹏(寈峰),阿里巴巴中间件技术专家

本次直播视频精彩回顾,戳这里!
以下内容根据演讲嘉宾视频分享以及PPT整理而成。

本次的分享主要围绕以下四个方面:

一、产品简介
二、功能架构
三、典型场景
四、实践操作

一、产品简介
1.GTS是什么
GTS是一款也是唯一一款专注于分布式事务问题的中间件。我们把它定义为一站式的分布式事务解决方案。也就是说有了GTS之后,用户不再需要考虑到回滚接口的开发,幂等,以及分布式事务引发的其它异常等等。只需要接入GTS,GTS可以保证应用的所有事务问题。我们把事务问题归结为四个方面,也是GTS现在可以解决的四大事务问题。
第一类是跨库问题,实际上,跨库问题是最早碰到的事务问题。这里跨库是指两方面,一方面是有很多的分布式数据库,分布式数据库如果没有事务功能的话,GTS可以为它提供分布式事务的服务。还有一种是跨异构的数据库,或者同构的数据库。比如说业务系统要访问多个MySQL的实例,或者说访问一个MySQL,ObenBase这种异构的数据库,那这时GTS也可以保证跨异构数据库,或者同构数据库的一致性。
第二类是微服务化的事务,在后续这个会有非常广的应用。因为微服务到来之后,传统的服务被划分的粒度非常细。之前一次的RPC调用现在可能要变成若干次RPC调用,这时候它不可避免的会牵扯到事务的问题。我们在GTS公测之后,2月份我们陆陆续续接过来很多的公有云用户,很多都是因为企业在数字化转型的过程中,微服务化之后碰到了跨事务的微服务调用。比如用户买东西的时候,需要保证订单服务,也需要保证库存服务,也要保证它们的一致性。现在很多主流的微服务框架,SpringCloud,Double,EDAS它们实际上框架并没有独立的事务解决方案。这是GTS未来会公开使用的重点场景。
还有一类是消息事务。现在有很多消息组件,有的支持事务功能,有的不支持事务功能。GTS也可以支持消息事务。还有一类是混合事务。有的时候业务系统又要进行本地的SQL操作,还要进行远程的RPC调用,而且还要发消息,这时候GTS可以支持整个事务链上有多种类型的事务,保证多种事务的一致性。
2.GTS与其他解决方案对比
在GTS出现之前,业界也是有其它的事务解决方案,第一类是XA方案,第二类是补偿方案,也就是TCC的方案,第三类是消息的方案。
XA方案最早是解决跨数据库的事务问题,它的优势是接口标准化,使用门槛比较低,而且能够达到强一致性的效果。但是有个不理想的是使用了阻塞协议,在高并发的场景下性能不是很理想。而且在微服务化之后可能没办法解决微服务的事务问题。第二类补偿性方案(TCC)其实是比较符合也无需求的,因为它大部分都是按照特定的业务去做开发,它的效率其实取决于开发者的水平。TCC的方案中小型企业其实用的比较少,一方面它需要的人力成本非常高,对开发者的各方面能力有很高的要求。这个方案的不足之处在于非常复杂,每个服务都需求提供一个反向的接口。比如一个下单的操作,还需要一个下单方法的反向回滚的方法,所以说运维成本比较高。第三类消息方案是通过消息异步的补偿一致性,这个方案实现相对简单。但是需要建立独立的消息系统,应用需要跟消息系统耦合在一起,而且需要业务实现幂等,它要求最终一致性,场景会受一些限制,对一致性要求非常搞的场景不太适应。
3aed1334a96fe6131b6cfcfdf66c6d726781e1e9
XA的方案是在资源的层面解决事务问题,因为XA有一个资源管理器是跟数据库放在一起,所以它对于资源是有限制的,现在绝大部分只能支持关系型的数据库,还不是所有的关系型数据库,场景是受限制的。那补偿方案和消息方案是从应用的层面解决事务问题,它们会和应用耦合在一起。GTS跟这三者不同点在于,它既不在资源层也不在应用层,它是在中间件层解决事务的问题,这是它们本质的区别。在中间件有什么好处呢,大概有三点。第一,因为在中间件层,是独立的一层,它可以解决跨资源的问题。如果应用去访问不同类型的问题,比如访问OpenBase,还有MySQL,以及Oracle,这时还需要保证一致性。XA方案很难做到这一点,GTS可以保证异构资源事务的一致性,异构的数据库,甚至文件系统。另外一个好处是GTS不在应用层面,就可以解决服务化问题。另外它和应用是松耦合的,这样应用会更加清亮,比如说一个微服务要解决事务的问题,要实现幂等等操作,它会把非常复杂的解决事务的逻辑嵌入到微服务里,这时微服务已不是微服务,变得非常重。GTS解决事务问题时会让微服务更加简单更加清亮化。而且GTS独立开来,从中间件这层解决事务,便于应用移植。
5810de23bb1b8ce8d18767deb99d506b52d48aef
3.GTS优势
下图是从技术层面列的GTS的特点和优势。GTS会提供事务的完整解决方案,第二个是GTS对应用的侵入性非常低,这一点意味着它使用的门槛就很低。如果需要用EDAS的话,只需要加一行注解就OK了,就可以接入到事务中。而且我们还提供了API接入模式,使用非常方便,基本上使用Java开发半年的使用者就可以很方便的使用我们的GTS,我们官方已经有非常完善的文档和样例。还有GTS的性能非常强,通过很多次测试,包括做了要求非常严格的金融行业的测试。是传统的分布式事务的10倍,4c8g集群可达1.5万TPS。我们今年春节的时候淘宝活动,当时有个应用达到了10万TPS,是使用了三个9个节点的集群支持这个应用。除此之外,GTS有高可用的特点。它支持应用宕机,节点故障等各类异常情况下保证数据严格一致,并支持同城主备及两地三中心部署。
75cc6d596ac25823a60eb6383d777b5923703072
4.GTS产品历史
大家熟悉的很多平台后面都有GTS的支撑,如淘宝,阿里音乐,盒马生鲜,农村淘宝等等。另外有一些是专有云用户,很多政府部门要建设自己的专有的云平台,GTS也可以以专有云的形式输出。国家的电动汽车交易是基于GTS来保证事务的功能的。另外一部分是公有云用户,大部分是发布阿里云公测之后过来的,包括物流,金融,共享单车,新零售等等一百多个用户。
43d9501983a7d36fc7df31688536c11362ec5059
GTS从2018年5月21日开始商用,首发第一个月内七折,按不同规格分,最高规格年付是六折。
c9f0541dc73ea4246aa37f46739fe6efa2fa1f76

二、功能架构
1.总体架构
下图是GTS总体的功能架构,左边是总体服务端的集群,GTS一个标准的集群有三个节点,三个节点之间是互备的。右边是GTS客户端,是以SDK的形式与应用集成在一起。客户端负责全局事务的发起,全局事务的结束,全局事务的回滚,分支事务的提交,分支事务的回滚等操作。服务端是全局事务整个生命周期的管理,会记录每个事务的运行状态,每个事务有哪些分支事务,每个分支事务的运行状态。GTS可以跟服务的框架集成,解决服务化事务问题,也可以跟资源对接,解决应用跨资源事务问题。
5e48bededf71f27d8a114a582d599d48cc6a1253
2.事务模型
GTS事务模型非常简单,全局事务包含若干个分支事务。举例来说,一个SQL里面有若干条SQL语句,每个SQL语句就是分支事务。全局事务标识为xid,分支事务标识为branchid,因为服务端会记录每个分支事务的状态,通过模型来组织事务的存储。
1fe2cd0bc0447f62653cf9f54ab2b859922db755
3.事务协议
下图是客户端和服务端交互的协议。这里的客户端包含两部分,一个是GTS Client,还有一个是RM,也就是资源管理器,通常跟服务集成在一起。首先客户端会往Server端要一个事务的标识xid,拿到之后把xid传给RM,每个RM可能是一个或几个事务分支。RM拿到xid之后会往Server端要分支事务的id,拿到id号代表它以及启动一个分支事务了,这时它可能会提交本地的SQL语句,之后把提交的状态汇报给Server。如果所有的RM执行完毕之后会返回给Client端,Client端告诉Server要全局提交事务,这时整个全局事务就已经提交了。
23b0135b11a5ebe5386e06494c90a36ae3d524d9
4.与微服务集成架构
下图表示的是有一个业务应用需要调用三个微服务,业务应用通过Server端拿到xid之后,它会把xid传到各个微服务做调用,,每个都做一些数据库操作和资源的访问。如果在调用微服务C的时候失败了,GTS需要回滚前两次操作,回滚是GTS要做的,跟TCC不同。如果有个微服务失败,传到业务应用,业务应用告诉Server,Server会把跟GTS集成咋一起的SDK,SDK里面有RM,RM会让微服务A和B分别做回滚。因为GTS在每次SQL操作之后会记录SQL前后镜像的信息,也就是说之前的数值是知道的,避免幂等的问题,没有必要做反向接口,而是直接回滚就可以了。这一点非常重要,很多从事TCC开发的人员在这方面是非常头疼的。
90646ba1875761f027e7666a438e22b2d26bc12b
5.容错机制
GTS在服务端,客户端发生异常的时候都可以保证业务的连续性。比如下图,GTS的服务端是个三节点的集群,有三个应用。GTS有一些核心的数据信息,包括锁信息。用户如果牵扯到并发的修改镜像记录是需要有锁的,GTS会把锁信息和各个事务的一些执行状态记录下来,这就是它的关键信息。这些信息是互备的,S1的备到S2上,S2的备到S3上,S3的备到S1上。如果APP正在发生回滚操作的时候,S3挂掉了,APP的RM是知道S3的备用节点的,由备用节点去驱动,完成回滚的操作。
ce55da7562a1b67eb2a765e00112fc2c5baf096b
还有一种情况是应用宕机。GTS也可以保证业务的一致性,当然前提是应用是负载均衡部署。
如果说在全局回滚的时候,APP1挂掉了,GTS是知道跟APP1负载均衡在一起的其它APP。GTS可以驱动其它的APP来完成APP1没有完成的回滚的操作。可以完成的核心在于数据在下面的数据库里,只不过找一个跟APP1操作相同,有权限操作相同数据的其它应用干这件事情。
2b67bdac9b9033e26916ba76f2b7c0dc672aff14
6.扩展机制
GTS可以支持应用的横向扩展,如果说三个节点APP非常多,可以通过物理组将这些集群映射到不同的GTS集群。
33eb5499654f0ad4eedbbfa5c00b64cf330685b5
GTS有两个使用模式,AT和MT。AT是自动模式,可以完全自动回滚,可以覆盖90%左右的业务场景,所以比较推荐使用AT模式,它对业务无侵入,高效,强一致性。还有一种MT模式是GTS推出的兼容TCC的模式,因为有一些情况下是无法避免的要使用TCC模式。而且GTS可以实现两种模式的组合。
5b7b812361f86b080c708187c456ba062e5fb40d

三、典型场景
场景一:跨数据库场景
第一种GTS应用场景,支持跨数据库的事务问题。应用有跨库的操作,跨库的一致性都可以得到保证。
9104cb357796c81b55ff65bd15e9341675970cc3
场景二:微服务调用事务问题
微服务调用如果有嵌套的场景,GTS可以保证这个调用链条中的事务,也可以保证调用的一致性。
be72b66f1dfe40ff14dd8d17058deec17ed09e66
场景三:多系统集成事务问题
我们有一个放款应用,它需要调用本地金融系统的三个服务以及第三方系统的服务。用信用核心调用户的信用,而且用风控中心的服务评估放款的风险,之后还需要调用额度中心生成用户放款的额度,最后去银行调银行系统放款。整个调用链需要保证,如果放款失败的话需要回滚前三个服务,因为前三个服务都是由SQL写入。这个场景复杂的点在于不可能回滚第三方系统银行的账户,所以这时候需要用到AT+MT混合的模式。在调用前三个服务的时候使用AT模式,那在调用支用和合法校验的时候必须要使用MT模式,也就是银行那边给你提供一个反向接口,或者自己做一个补偿的反向机制。
d58cd8f875df28c0584d88fdab533af26c01d9a6
场景四:混合事务问题
混合事务问题应用也很广,我们有DRDS,MQ,EDAS的调用,只要在一个调用链中,GTS都可以解决。
dc3a22d6f65b35267337799cf63b1b9a9d04da18
应用案例
我们有一个公有云用户,是共享电动自行车的公司。它有很多的服务,是基于SpringCloud构建的微服务,里面有很多订单,优惠,支付,车辆,运维等很多应用模块。有两个典型的服务就是借车和还车。借车有车况检测,生成订单,变更状态,推送订单消息到MQ,这时候这个调用链中有服务,也有消息的场景。这个过程是通过GTS来保证事务的一致性。还车的时候需要锁车,结束订单,推送消息到MQ,获取优惠券信息,扣款,也是典型的事务。用户从3月份开始上公有云,线上的系统也跑了一段时间,非常稳定,每天的事务量大概在几百万,非常饱和。
eb14038efae923697d259421667eb9cbb7c7b43c

四、实践操作
下面简单介绍GTS的用法。阿里云的官方网站上有GTS的一些文档和样例工程,这里截取样例工程的案例来展示。下图的案例是个非常简单的转账操作,其中有两个分支,一个是从db1的账户里扣款,然后去另一个账户存款。在后面做一个检测,看刚刚扣款的账户是不是小于零,如果小于零就是没钱了,抛出异常。上面的红色的一行是GTS注解,可以划分事务的边界,如果抛出异常,整个就可以回滚。
23ff00f2646703ec2ddd1ff4fe674ac10b7af0f9
使用EDAS客户端也跟上面类似,上面是直接操作数据库。这里也是先加钱再减钱,使用Transaction注解开启一个事务。
ddf800501d20051a8cd3094f0e3d0129bc89db28
下图是EDAS服务端扣款的操作,实际上没有GTS的痕迹,纯业务操作,GTS对服务端代码是没有侵入的。
7d67a7b3e38efef8d1352d69fb967c9ee4745588
下图是EDAS的配置文件,需要注意的是这个需要按照GTS的要求进行修改。首先数据源是GTS自己带的txc.datasource,需要这个数据源主要是需要截取镜像信息做回滚。还有一个是TxcTransactionScaner需要配置一下,有三个参数。第一个是逻辑事务分组,主要来标识一个GTS用户的,后面accessKey和SecretKey是阿里云帐号的信息。
5387d0663f57443e0712f058f4ca881f3db11c50
下图是MT模式下的操作,在金融行业里面TCC模式用的比较多。MT模式首先需要加注解界定事务的边界,然后通过MtBranch注解告诉GTS第一阶段的资源锁定方法是哪个,然后提交的方法,第二阶段rollback方法是哪个。实现这个接口之后GTS可以按照不同的方法调用。
c8ede8aa71174bbf47ac8a157883e1a7249719b8

本文由云栖志愿小组董黎明整理

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章