一文总结 GaussDB 通信原理知识

摘要：从发展历程到通信模型设计，到你了解一下 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。数量有限制，但可以调整。

image

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 的返回数据，作为结果集返回。

image

问题 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 被应用取走。

image

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 获得锁后发送数据。节点数越多冲突越少。

image

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

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

image

问题 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。

image

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

点击关注，第一时间了解华为云新鲜技术~