其他分享
首页 > 其他分享> > 分布式事物-GTS的原理、架构与特点

分布式事物-GTS的原理、架构与特点

作者:互联网

上一篇博客《分布式事务--Fescar》中我们已经了解到Fescar相关的知识,Fescar也是基于阿里巴巴的GTS开源的。这篇转载博客理解学习一下GTS相关的知识内容。

         全局事务服务(Global Transaction Service,简称 GTS)是阿里新推出的分布式事务处理方案,对其深入分析的资料相对匮乏。本文的目标是剖析GTS的技术路线,厘清其优势与约束。文章参考了GTS公开的专利、产品文档、相关网页,文章中肯定有不准确的地方,欢迎各位同学拍砖与指正。

一、GTS的目标

GTS是一个面向互联网交易场景的分布式事务解决方案。

制约分布式事务的三个因素

分布式事务是互联网交易场景面临的关键问题之一。不同于搜索、社交、联机分析应用,电子商务、支付是典型的交易场景,数据的错误会带来严重的后果,对数据的一致性与可用性有很高的要求。互联网环境带来了海量的数据容量、连接数与访问量,单一数据库节点无法应对,成为整个系统的瓶颈。为解决单一数据库成为瓶颈的问题,通过数据拆分实现数据库能力的线性扩展。数据拆分是使用分库分表的方式,将数据存储在多个数据库节点,利用分布式数据库平台解决数据库瓶颈的问题。分布式数据库环境中,一个事务会跨越多个数据库,面临分布式事务处理的问题。

分布式事务解决方案面临应用灵活性、数据一致性、性能三者的挑战。目前已有多种成熟方案,每种方案都是对这三个方面做出的取舍。

相互制约的三个因素为:

现有分布式处理方案

现有成熟的分布式解决方案包括XA两阶段提交、可靠消息与TCC模式等类型。XA两阶段提交属于强一致事务,可靠消息与TCC模式属于柔性事务。

XA两阶段提交

XA 是指由 X/Open 组织提出的分布式事务处理的规范。XA规范主要定义了Transaction Manager(TM)和Resource Manager(RM)之间的接口,结构如下图所示。

 

2018-01-01-XA.png

XA协议的流程可大致分为三个步骤:

TM与RM之间的提交处理,采用两阶段提交协议。TM在第一阶段对所有的参与事务的RM请求“预备”操作,达成关于分布式事务一致性的共识。事务参与者必须完成所有的约束检查,并且确保后续提交或放弃时所需要的数据已持久化。在第二阶段,根据之前达到的提交或放弃的共识,请求所有参事务的RM完成相应的操作。

提交事务的过程中需要在多个资源节点之间进行协调,而各节点对锁资源的释放必须等到事务最终提交时,所以两阶段提交在执行同样的事务时会比一阶段提交消耗更多的时间。当事务并发量达到一定数量时,就会出现大量事务积压甚至出现死锁,系统性能和处理吞吐量就会严重下滑。

可靠消息

可靠消息的一种可能实现的结构如下图。

 

2018-01-01-MSG-DT.png

说明:

通过消息进行事务异步的方式,可以保证业务数据操作和消息的发送同时执行成功或失败,保持了事务的最终一致性。

采用可靠消息的方式,在两个事务间实现分布式事务时,可以很好地满足事务最终一致性以及事务的回滚,但如果一个事务上下文中超过两个事务操作后,需要开发人员实现整个事务流程的操作日志的记录、每个事务分支的回滚以及整个流程的准确调度。

TCC模式

TCC模式为全局事务执行提供了一个框架,开发人员只需要实现每个事务分支的回滚,不需要记录整个事务流程的操作日志。TCC模式结构如下图。

 

2018-01-01-TCC.jpeg

标题

说明:

TCC业务包括两个阶段完成:

小结

可靠消息与TCC模式通过避免XA两阶段提交对数据资源的长期锁定提升了性能,通过在数据库外部实现事务机制达到了最终一致性,但牺牲了应用灵活性,需要开发人员实现事务检查与回滚的细节,面临着花费大量精力保证应用正确性的问题。

GTS目标是在性能开销可接受的情况下,由GTS统一处理全局事务的故障恢复与并发控制,对应用开发屏蔽事务处理的细节,从而提升应用的灵活性与数据的一致性。

二、GTS的技术路线

GTS采用基于XA架构优化的技术路线,在保留XA架构灵活性的优点下,通过将XA提交中的第一阶段与第二阶段解耦,将提交过程转换为第一阶段本地事务提交+第二阶段异步清理的方式,从而提供提升系统性能,同时通过在GTS内部维护应用级别的日志与锁信息,实现了全局事务的回滚与并发控制。

GTS方案认为XA性能低效的根本原因是采用了阻塞协议。在分布式事务提交的第一阶段等待最慢的一个事务分支完成,即使在不存在锁冲突的情况下,各事务分支的数据库连接依然会被挂起所占用的资源都不能够释放,以防止全局事务提交前释放资源所造成的数据不一致。对于业务流量极高的大规模互联网企业,难以接受 XA 两阶段提交协议所带来的巨大性能开销。

GTS架构包含的组件与XA完全相同,示意架构如下图。

 

2018-01-01-GTS-CONCEPTS-ARCH.png

标题

GTS全局事务处理流程与XA一致,也包括全局事务注册、数据访问与全局事务提交三个步骤,但在第二步与第三步的内部处理上与XA不同:

GTS与XA在全局事务的故障恢复处理与并发控制采用了不同的实现机制:

三、GTS的架构与处理流程

架构

下图描述了GTS一种可能的实现架构。

 

2018-01-01-GTS-IMP-ARCH.png

标题

与XA架构相同,GTS架构由应用、事务管理器、资源管理器三个部分组成。资源管理器由事务分支处理模块、镜像查询构造模块、并发控制模块、恢复控制模块,以及存储在数据库中的GTS事务信息(GTS锁表与GTS日志表)等组成。

字段名 字段类型 字段描述
ID 整数 自增主键
TABLE_NAME 字符串 表名
KEY_VALUE 整数 数据行ID
XID 字符串 全局事务标识
XLOCK 整数 互斥锁标记
SLOCK 整数 共享锁标记
BRANCH_ID 整数 事务分支标识
字段名 字段类型 字段描述
ID 整数 自增主键
GMT_CREATE 时间 创建时间
GMT_MODIFIED datetime 修改时间
XID 整数 全局事务ID
BRANCH_ID 整数 分支事务ID
ROLLBACK_INFO longblob 查询语句、前像与后像
STATUS 整数 状态
SERVER 字符串 分支所在DB IP

主要流程序列图

分别描述了insert/delete/update操作、读已提交操作、提交操作和回滚操作等四个操作的序列图(一种可能的实现方式)。

insert/delete/update操作流程序列图

 

2018-01-01-SEQ-INSERT-DEL-UPDATE.png

标题

读已提交操作流程序列图

 

2018-01-01-SEQ-READ-COMMIT.png

标题

提交操作流程序列图

 

2018-01-01-SEQ-COMMIT.png

标题

回滚操作流程序列图

 

2018-01-01-SEQ-ROLLBACK.png

标题

阿里官方案例

GTS产品网站给出了一个交易类事务中最典型的转账案例

2017云栖大会 GTS产品介绍中,给出了使用GTS与不使用事务(1PC)测试对比。下图,GTS比1PC的性能损耗在10%,远远小于2PC方式,表现出优异的性能。

2018-01-01-PERF-COMP.png

四、GTS的优势与约束

与基于消息队列与TCC补偿模式的分布式事务相比,在性能满足的情况下,GTS更好的应用灵活性与数据一致性:

根据GTS实现机制的特点,其应用场景上有以下约束:加锁操作记录数量不能太大,操作冲突不能太多,加锁时间不能太长。违法以上约束时,GTS内部会占用过多资源、锁冲突和回滚增加,导致性能的下降。电商、物流、金融、零售行业中的核心交易场景有着高并发,高性能,单次操作数据集小,事务响应时间敏感的特点,GTS类方案在此类场景中有着广泛和良好的应用前景。

五、参考

专利

网页

 

原文地址:https://yq.aliyun.com/articles/334238

标签:事务,架构,XA,GTS,提交,操作,分布式
来源: https://blog.csdn.net/zhong_jianyu/article/details/88627716