MPPDB通信库发展历程(通信原理知识点总结)

从发展历程到通信模型设计，到你了解一下GaussDB通信原理知识。下面，让我们一起来看看。

MPPDB通信库发展历程

1、Postgres-XC

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

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

2、V1R3

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

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

3、V1R5-V1R7C00

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

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

4、V1R7C10

方法：TCP代理通信库。

缺点：CN和DN之间的物理连接数也会暴涨。

5、V1R8C00

方法：CN和DN之间也采用逻辑连接实现，即CN多流。

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

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

通信模型的设计

1、Pooler通信模型

问题2：连接池上的CN、DN是否存在交集，即poolA中的DN在poolB中也存在？

解：不存在。

问题3：CN和CN的连接是做什么的？为什么设计连接池连接CN上的PG线程？CN上为什么有多个PG线程，有什么用途？

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

问题4：DN上为什么有多个PG线程，有什么用途？

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

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

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

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

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

2、DN间stream线程通信模型

执行计划需要使用多个线程进行执行，包括1个CN线程和每个DN上3个线程t1-t3。每个DN节点都有3个线程是因为数据是分布到每个DN上的，在执行查询过程中，查询的每个阶段每个DN都要参与。

自下而上是数据流，自上而下是控制流。具体执行过程如下：

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

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

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

SCTP通信库设计

1、概要

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

2、架构

• TCP Channels：TCP控制通道，控制流走此通道；
• 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代理通信库的发送端实现，producerA和producerB分别给DN1发送数据，为保证发送端head+data发送的完整性，producerA首先需要对单个物理连加锁，此时producerB处于等锁状态，producerA将数据完整发送到本地协议栈后返回，并释放锁，producerB获得锁后发送数据。节点数越多冲突越少。

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

解：不影响，因为有缓存buffer。

问题11：数据丢失，永远无法达到head怎么办？一直缓存？

解：不会丢失，TCP协议有保证。

CN多流实现

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

1、CN端流程：

• 建立连接：CN调用Libcomm的gs_connect与DN建立连接，入参中指明建立双向逻辑通道，使用相同的nidx，sidx同时初始化发送和接受的mailbox，通过发送流控线程通知接收端;
• 等待DN返回结果：通过判断发送mailbox的状态，确认DN端已成功建立的逻辑连接（发送流控线程收到DN端的CTRL_READY报文）;
• 发送startuppacket：通过PQbuildPGconn，初始化libpq的pg_conn结构体，生成startuppacket，随后通过gs_send发送startuppacket给DN端;
• 等待DN PG线程初始化：通过LIBCOMMgetResult，等待DN端返回ready for query报文，之后认为连接建立成功。

2、DN端流程：

• 初始化发送、接收mailbox：DN端接收流控线程识别到连接请求来自CN后，调用gs_build_reply_conntion，注册CN的信息，初始化发送mailbox，随后初始化接收mailbox，最终通过流控线程返回CTRL_READY报文，表示逻辑通道建立成功;
• 创建unix domain sock：DN端接收流控线程，创建一个unix domain sock，将生成的逻辑连接地址通过该通道发给postmaster主线程;
• fork postgres子线程：postmaster主线程的serverloop**到unix domain sock后，接收逻辑连接地址，保存到port结构体中，随后fork postgres子线程（沿用原有逻辑）;
• postgres线程初始化完毕：在pg线程完成初始化后，首先给CN回复ready for query报文，随后进入ReadCommand函数，等待CN发来的下一个Query。

本文分享自华为云社区《GaussDB通信原理总结》，原文作者：Caesar.D 发。