为什么说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也越长，这么多的活跃事务都需要取含有很长活跃事务列表的快照信息，会很快造成瓶颈。