GaussDB通信原理总结

举报
Caesar.D 发表于 2021/01/30 15:59:01 2021/01/30
【摘要】 一文总结GaussDB通信原理总结学习分享。
  • MPPDB通信库发展历程
  1. Postgres-XC

方法:采用libpq通信库实现CNDN之间的连接,CN负责计算,DN仅进行数据存储。

缺点:随着计算任务的不断增大,CN计算出现瓶颈,且白白浪费DN的计算能力。

  1. V1R3

方法:提出分布式执行框架,将计算下推到DN上执行,DN不仅作为存储同时承担计算任务。由于每个DN只存储有一部分数据,因此DN间也需要进行通信,采用stream线程TCP直连,每个连接都需要一个TCP端口。

缺点:随着集群规模的增加,DN之间的连接数不断增加,在大并发场景下需要大量的TCP端口,而实际情况是由于单机TCP端口只有65535个,TCP端口数严重限制了数据库的集群规模和并发规模。

  1. V1R5-V1R7C00

方法:结合SCTP协议的多流优点,DN间的通信采用SCTP通信库架构,使用逻辑连接来代替物理连接,用来解决DN之间连接太多的问题。

缺点:SCTP协议本身存在的内核BUG,通信报错。

  1. V1R7C10

方法:TCP代理通信库。

缺点:CNDN之间的物理连接数也会暴涨。

  1. V1R8C00

方法:CNDN之间也采用逻辑连接实现,即CN多流。

 

问题1DN间是查询结果的通信还是原始数据的通信?

解:既有查询结果,也有原始数据;DN之间的数据交流是Hash之后,各个DN根据所需获取。

 

  • 通信模型的设计

    1. Pooler通信模型

 

问题2:连接池上的CNDN是否存在交集,即poolA中的DNpoolB中也存在?

解:不存在。

问题3CNCN的连接是做什么的?为什么设计连接池连接CN上的PG线程?CN上为什么有多个PG线程,有什么用途?

解:CNCN之间连接是为了数据同步等,包括建表之后的信息交汇。CN上的PG线程也是为了用户查询建立。

问题4DN上为什么有多个PG线程,有什么用途?

解:一个查询操作就是创建一个新的PG线程。

问题5:如何理解gsql客户端退出时,只退出PG线程和agent代理线程,而取到的slot连接会还回database pool

解:slot连接退回到pooler,下次连接可以直接获取,若不存在,则重新创建。

问题6DN间的TCP连接数:C = (H * D * Q * S* D,为什么最后乘以D,而不是(D - 1/ 2 ? 此外,这个公式是否存在高重复,每次查询都要建立DN间的通信,而不考虑重复性?DN间的通信线程数量是否有限制?

解:数据是双向通信,但执行算子是单向的,所以不能除以2。数量有限制,但可以调整。


    2. DN间stream线程通信模型

执行计划需要使用多个线程进行执行,包括1CN线程和每个DN3个线程t1-t3。每个DN节点都有3个线程是因为数据是分布到每个DN上的,在执行查询过程中,查询的每个阶段每个DN都要参与。自下而上是数据流,自上而下是控制流。具体执行过程如下:

  • 每个DNt3顺序扫描table表,将表数据广播到所有DNt2线程;
  • 每个DNt2接收t3的数据,建立hash表,然后扫描store_sales数据与customer表进行hashjoinjoin结果进行哈希聚集后,重分布发送到对应DNt1线程;
  • 每个DNt1线程将收到的数据进行第二次哈希聚集, 排序后将结果传输到CN;
  • CN收集所有DN的返回数据,作为结果集返回。


 

问题7DN上是否执行查询操作?DN广播的数据是否属于同一个数据表?每个DN都广播数据,那最后所有DN的数据是否相同?图中t2发送给所有DNt1?、

解:执行,DN上存的数据是表的几分之几,不是整个表,也不是一个表的部分,是所有表的一部分,这样做是为了并发。DN数据不相同,因为各取所需。

 

  • SCTP通信库设计

    1. 概要


  • SCTP 协议:一种可靠、保序协议,支持message-based模式,单个通道支持65535个流,且多流之间互不阻塞,利用该特性,可以打破设备物理连接数对大规模集群节点间通信的限制,支持更大规模的节点规模。
  • 通道共享:每两个节点之间有一个数据传输单向SCTP物理通道,在这条物理通道内部有很多逻辑通道(inner Stream),每个stream流由producer发送到consumer,利用SCTP内部支持多流的特性,不同的producer & consumer对使用通道中不同的流(SCTP),因此每两个点之间仅需要两个数据连接通道。
  • 通道复用:查询完成后,物理通道中的逻辑连接关闭,物理连接不关闭,后面的查询继续使用建好的物理连接。
  • 流量控制:采用pull模式,因为SCTP通道的所有流共享内核的socket buffer, 为了避免一个连接发的数据量过大,consumer端却不接收,导致kernelbuffer被填满,阻塞了其他流的发送,增加了流控,给每个流设置一个quota, 由接收端分配,当有quota时,告知发送端可发送数据,发送端根据发来的quota值,发送quota大小的数据量,实现接收端与发送端同步控制;为了保证控制信息的可靠性,将控制信息和数据通道分离,流控信息走单独的一条双向TCP控制通道。

    2. 架构

  • TCP ChannelsTCP控制通道,控制流走此通道;
  • SCTP Channels:SCTP数据通道,包含很多stream流,数据流走此通道;
  • Send Controller发送端流控线程:gs_senders_flow_controller(),收发控制消息;
  • Recv Controller接收端流控线程:gs_receivers_flow_controller(),接收端用于发送和接收控制报文,与代理接收线程不同,代理接收线程接收的是数据,而接收流控线程接收的是报文;
  • Receiver代理接收线程:gs_receivers_loop(),用于接收数据的线程,从sctp数据通道中接收数据,将数据放到不同逻辑连接的不同cmailbox报箱中,并通知执行层的consumer工作线程来取,取走后,有空闲的buffer时,接收端流控线程会通过tcp控制通道通知发送端还有多少空闲内存,即还有多少quota可用于继续接收数据;
  • Auxiliary辅助线程:gs_auxiliary(),由top consumer,每个两秒检查一下,处理公共事务,如DFX消息,Cancel信号响应等;
  • 数据PULL模型:每个逻辑连接有quota大小的buffer,需要数据时将空闲buffer的大小(即quota)发送给发送端,发送端即可以发送quota大小的数据,quota不足时阻塞发送,直到接收端的buffer被应用取走。


 

  • TCP多流实现


TCP代理在现有的逻辑连接、代理分发、quota流控等实现的基础上,将数据通道从SCTP协议替换成TCP协议,TCP代理逻辑连接的实现基于head+data的数据包收发模型,在head中写入逻辑连接id及后续data的长度。

问题8:单机TCP只有65535个端口,SCTP呢?TCP多流和TCP在端口上的区别?TCP的三次握手是否依旧?

SCTP是基于消息流传输,数据收发的最小单位是消息包(chunk),一个SCTP连接(Association)同时可以支持多个流(stream),每个流包含一系列用户所需的消息数据(chunk)。而TCP协议本身只能支持一个流,因此我们需要在这一个流中区分不同逻辑连接的数据,通过在TCP报文的head中写入逻辑连接id及后续data的长度来区分,这样虽然TCP只有一个数据包组成,但每个数据包包含多个块,实现了TCP的多流。同时发送时需保证整包原子发送。

 

问题9:如何多流?是多个通道同时发送head+data吗?

解:一个流发送完整的数据。多流是并发。

 

TCP代理通信库的发送端实现,producerAproducerB分别给DN1发送数据,为保证发送端head+data发送的完整性,producerA首先需要对单个物理连加锁,此时producerB处于等锁状态,producerA将数据完整发送到本地协议栈后返回,并释放锁,producerB获得锁后发送数据。节点数越多冲突越少。


问题10:加锁等待是否影响效率?SCTP的实现也是如此?

解:不影响,因为有缓存buffer

问题11:数据丢失,永远无法达到head怎么办?一直缓存?

解:不会丢失,TCP协议有保证。

 

  • CN多流实现

V1R8C00版本中,CNDN之间的链接使用libcomm通信库,即两个节点间仅存在一条物理通道,在该物理通道上使用逻辑连接通道实现并行通信。

  1. CN端流程:
  • 建立连接:CN调用Libcommgs_connectDN建立连接,入参中指明建立双向逻辑通道,使用相同的nidxsidx同时初始化发送和接受的mailbox,通过发送流控线程通知接收端;
  • 等待DN返回结果:通过判断发送mailbox的状态,确认DN端已成功建立的逻辑连接(发送流控线程收到DN端的CTRL_READY报文);
  • 发送startuppacket:通过PQbuildPGconn,初始化libpqpg_conn结构体,生成startuppacket,随后通过gs_send发送startuppacketDN;
  • 等待DN PG线程初始化:通过LIBCOMMgetResult,等待DN端返回ready for query报文,之后认为连接建立成功。
  1. DN端流程:
  • 初始化发送、接收mailboxDN端接收流控线程识别到连接请求来自CN后,调用gs_build_reply_conntion,注册CN的信息,初始化发送mailbox,随后初始化接收mailbox,最终通过流控线程返回CTRL_READY报文,表示逻辑通道建立成功;
  • 创建unix domain sockDN端接收流控线程,创建一个unix domain sock,将生成的逻辑连接地址通过该通道发给postmaster主线程;
  • fork postgres子线程:postmaster主线程的serverloop监听到unix domain sock后,接收逻辑连接地址,保存到port结构体中,随后fork postgres子线程(沿用原有逻辑);
  • postgres线程初始化完毕:在pg线程完成初始化后,首先给CN回复ready for query报文,随后进入ReadCommand函数,等待CN发来的下一个Query

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。