摘要：从倒退历程到通信模型设计，到你理解一下GaussDB通信原理常识。

* MPPDB通信库倒退历程

  1. Postgres-XC

办法：采纳libpq通信库实现CN和DN之间的连贯，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代理通信库。

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

  1. 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。数量有限度，但能够调整。

  1. 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管制通道。
  1. 架构
  • 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报文，之后认为连贯建设胜利。
  1. 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 发。

点击关注，第一工夫理解华为云陈腐技术~