专栏首页数据库架构之美为什么说GTM是所有PGXC架构分布式数据库无法逾越的性能瓶颈?

为什么说GTM是所有PGXC架构分布式数据库无法逾越的性能瓶颈?

PGXC

熟悉pg的人对pgxc都不陌生,pgxc最初由stromdb公司开发,应用于商业,后来被TransLattice收购并将其开源,也就是现在的pgxl。Pgxc是基于pg的非常成熟的分布式架构,是一款混合负载的htap数据库。国内也有很多基于pgxc来做的分布式数据库,例如华为GaussDB-A,腾讯Tbase,亚信antdb等或多或少都借鉴了pgxc的架构理念。pgxc的总体架构大家都很清晰了,不再赘述。

GTM

Gtm的作用一句话概括就是:为了保证数据的全局读一致性。这里有个误区,可能有人认为如果没有gtm就会造成节点间数据不一致,这种说法是错误的,gtm是为了保证某一时刻读到一致的数据,而写一致性是通过两阶段提交保证的。

从上面的图可以看到GTM主要与协调节点进行交互,协调节点开启一个事务首先需要去gtm取全局事务号和事务快照信息,GTM成为整个架构的瓶颈有多方面原因,这也和与cn间的交互有很大关系,下面我们再分析一下有哪几方面原因。

01

网络收发包瓶颈

我们在压力测试中发现一个比较奇怪的现象,集群中gtm主节点所在服务器cpu很高,但是其他cn、dn所在服务器cpu并不高,这样基本定位集群瓶颈在gtm。再进一步分析,gtm服务器的网络流量明显比其他服务器高,我们开发了一个脚本抓取每10s的网络包数,发现网络包数相比dn服务器高出很多,同时随着我们压力程序的并发数的增加,gtm服务器网络包数也在不断增加,但是增长的趋势是趋于平缓,最终在大概180并发时,gtm的网卡流量包数不再上涨,tps也达到最大值,继续增加并发,tps不再增长。Cpu高的一个原因是这么多流量包已经到达cpu的处理瓶颈。

我们看到这么多流量包其实是因为任何一个事务的开启cn都需要去gtm取事务号和快照,常高并发会造成短时间内cn到gtm的请求激增,网络流量突增,那有人可能有疑问,cn和gtm交互,为什么cn的网络没有瓶颈?因为集群中cn不止一个,cn的数目在部署时可以根据业务并发数进行调整,并且流量会通过lvs或者f5负载均衡到每个cn,所以cn和gtm是多对一的关系,所有cn的请求一股脑发到gtm,造成gtm的处理瓶颈。

针对网络收发包瓶颈,其实有几方面可以改进。

首先在产品设计方面,可以考虑将全局事务和本地事务进行区分,事务开启时先判断事务是否是全局事务,如果是本地事务则直接下发dn,不经过gtm,因为真实业务场景,可能80%以上都是本地事务。

另外在使用上,可以考虑将网卡由主备绑定模式改为负载均衡模式,并且进行cpu网卡的绑定,也是有一定的效果。

02

GTM组件处理上的瓶颈

这个其实和上面是有关联的,根因是由于高并发造成的gxid事务号分配的瓶颈,这个和架构其实也有一定关系。通常生产系统中gtm不会只有一个,一定有至少一个备机,而且为了保证事务号不丢失,主备要同步当前事务号信息。我们在进行高并发测试时,观察gtm的日志,发现日志刷的非常快,内容都是主备同步xxx事务号成功。所以在高并发下,gtm组件已经分配不过来那么多的事务号,处理不了那么多请求,而且主备事务号的强一致同步也对gtm处理能力造成一定的限制。

针对这个问题,一方面可以考虑引入第三方存储来保存事务号,例如etcd集群,将gtm分配的事务号保存在etcd中,etcd本身是高可用,强一致的集群,这样将主备同步的问题交给了etcd集群去处理事务号数据一致的问题。

另一方面在分配事务号的速度上,可以考虑将事务号改为批量分配,一次分配多个事务号,并且进行缓存,当事务号用尽后gtm再进行分配。

03

PG自身快照原理的限制

我们知道postgresql通过快照(snapshot)来实现MVCC与事务可见性判断。对于read commit隔离级别,要求每个事务中的查询仅能看到在该事务启动前已经提交的更改,以及当前事务中该查询之前所做的更改,这都要通过快照来实现。

在pg中可以通过txid_current_snapshot来显示当前的快照snapshot,快照的文本表示是’xmin:xmax:xip_list’,xmin代表最早的仍然活跃的事务的txid。所有早于xmin的事务都将已经提交并且可见,或者回滚并且死亡。xmax代表第一个尚未分配的txid,所有大于或等于xmax的txid在快照生成时尚未启动,因此不可见。xip_list表示活跃的快照事务txid列表。该列表仅包括xmin和xmax之间的活动txid。

下图是一个快照的图例:

a:’100:100:’ 由于xmin为100,xid<100的事务不活跃,xid≥100的事务活跃,当前没有活跃事务。

b:’100:104:100,102’

xid<100的事务不活跃,xid≥100的事务活跃,100和102号事务当前活跃,101,103号事务不活跃。

快照最重要的作用是用于在并发事务下的元组可见性判断,我们知道pg的每条元组(tuple)头信息中也会记录事务的xmin和xmax信息,pg会根据元组的xmin、xmax与事务管理器中取得的快照信息进行一系列规则的判断,得到该元组是否对事务可见。元组可见性检查规则是非常复杂的一块内容,而且针对不同的隔离级别规则也不相同,也可以理解pg通过这些规则实现了不同的隔离级别。这块内容不再赘述。

再回到刚才的问题,快照为什么会成为gtm的瓶颈呢?原因在于xip_list,试想在非常高的并发下,活跃的事务列表将特别长,pg中一个事务号是32位的,当然有些分布式数据库已经改成64位了,如果有100个活跃事务会造成快照xip_list很长,同时这么多事务,每个事务都去取这么长的快照,在并发越高的时候会造成恶性循环,并发越多,活跃的事务越多,xip_list也越长,这么多的活跃事务都需要取含有很长活跃事务列表的快照信息,会很快造成瓶颈。

本文分享自微信公众号 - 数据库架构之美(databasekernel),作者:dbaer

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-02-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 商业银行如何进行分布式数据库选型思考

    在传统数据大集中的环境下,银行核心系统很容易发生故障,而且一旦发生故障,影响面将特别广,带来很大的舆论压力和监管压力,历史上大型商业银行核心系统故障的例子不在少...

    数据库架构之美
  • openGauss与PostgreSQL的对比

    华为公司今年6.30开源了openGauss数据库,openGauss数据库内核基于postgresql9.2.4演进而来,pg11.3版本数据库中共有290个...

    数据库架构之美
  • PostgreSQL中的预写式日志

    预写式日志write ahead log,是数据库保证数据完整性的重要数据结构。数据库管理器将数据库发生的变更记录写入wal日志缓冲区,进而写入wal日志文件中...

    数据库架构之美
  • 超多干货!支撑起腾讯公司计费业务的TDSQL

    深度技术文章,第一时间送达! 作者介绍: bluesea,腾讯金融云专家工程师,从事分布式数据库TDSQL研发工作。出版著作:《数据库查询优化器的艺术 原理解析...

    企鹅号小编
  • 支撑起腾讯公司计费业务的TDSQL(附PPT)

    作者介绍:bluesea,腾讯金融云专家工程师,从事分布式数据库TDSQL研发工作。出版著作:《数据库查询优化器的艺术 原理解析与SQL性能优化》、《数据库事...

    腾讯技术工程官方号
  • Python:正则表达式 re 模块

    re.match 尝试从字符串的起始位置匹配一个模式,如果不是起始位置匹配成功的话,match()就返回 None。

    丹枫无迹
  • javascript基础修炼(12)——手把手教你造一个简易的require.js

    许多前端工程师沉浸在使用脚手架工具的快感中,认为require.js这种前端模块化的库已经过气了,的确如果只从使用场景来看,在以webpack为首的自动化打包趋...

    大史不说话
  • 本周(5.6-5.12)云知声创下智能语音领域最大单笔融资记录 | 投融资

    镁客网
  • 【AI 引擎】2015年ACM Fellow 公布 | 机器人远程无线充电新技术 | 无人机交通法规出炉

    1.ACM公布了2015年ACM Fellow ? ACM,世界最大的领军计算社团,公布了对数据管理、机器人口语处理和加密学的进步和计算应用方面有杰出贡献的42...

    新智元
  • Python 08 re 正则表达式

    [0-9]代表的含意与\d就是完全一致的:一位数字;同理[a-z0-9A-Z_]也完全等同于\w

    py3study

扫码关注云+社区

领取腾讯云代金券