GaussDB(DWS)集群通信:详解pooler连接池

本文分享自华为云社区《GaussDB(DWS) 集群通信系列一:pooler连接池》,作者:半岛里有个小铁盒。

1.前言

适用版本:【8.1.0(及以上)】

GaussDB(DWS) 为MPP型分布式数据库,使用Share Nothing架构,数据分散存储在各个DN节点,而CN不存储数据,作为接收查询的入口,生成的计划会尽量下推到DN并行执行以提升性能,此过程中会产生大量的建连操作,使得通信开销变得很大。因此在大数据时代,集群规模越来越大,业务并发越来越高,数据库集群各节点间的通信压力也越来越大。GaussDB(DWS)集群通信技术,在大规模集群中可以承载高并发业务,能够实现高性能分布式通信系统。

2.背景

GaussDB(DWS) 中客户端执行查询流程如上图所示,其中具体的如下:

  1. 客户端向CN的监听端口发起连接;
  2. CN postmaster主线程accept连接,创建 postgres线程并将连接交给此线程处理;
  3. 客户端下发query到CN;
  4. CN的postgres线程将查询计划下发给其他 CN/DN,查询结果沿原路径返回到客户端;
  5. 客户端查询结束,关闭连接;
  6. CN上对应的postgres线程销毁退出;

CN与DN建连立流程,和客户端与CN建连立流 程基本相同。因此为了减少CN与DN建立连接,以及DN进程中postgres线程创建、销毁的开销,CN端实现了Pooler连接池。

3.Pooler连接池

如上图所示,CN的pooler连接池中会保存与其他CN/DN的连接,每一个连接在对端会对应一个postgres工作线程。

postgres工作线程是带状态属性的,如database,所以可以认为pooler连接池中的连接也是带属性的。不同属性间的连接是不能复用的,如上图所示,按不同属性切分为pool A/B/C等连接池。每个连接池中会存有连接往不同节点的空闲连接的数组,提供接口给外部使用或放入连接。

CN上的postgres工作线程在需要连接其他节点时,会创建一个本地agent,尝试从pooler连接池取跟本线程相同属性的空闲连接,pooler如果没有空闲连接,就会新建一个连接。连接交给agent后,可以视为线程私有。在线程退出时,agent才会将连接还给pooler。

接下来,我们从数据结构上来看看Pooler连接池实现原理:

空闲连接池

DatabasePool

/* All pools for specified database */
typedef struct databasepool
{
    char    *database;
    char    *user_name;
    char    *pgoptions; /* Connection options */
    HTAB    *nodePools; /* Hashtable of PGXCNodePool, one entry for each node */
    MemoryContext mcxt;
    struct databasepool *next; /* Reference to next to organize linked list */
} DatabasePool;

DatabasePool *databasePools = NULL;

进程级别数据结构

DatabasePool用于存储空闲连接,根据database,user_name,pgoptions三者来确定
如果通过三者查找到了,那么就取其中对应的nodePools,找不到则新加

nodePools中对应的数据结构为PGXCNodePool,用于存储本节点与其他每个cn/dn的连接,具体的保存如下

cn1[0,1,2,3,4,…]

dn1[0,1,2,3,4,…]

NodePool

typedef struct NodePool
{
    Oid nodeoid; /* Hash key (must be first!) */
    bool valid;
    ArrayLockFreeQueue pool;
} PGXCNodePool;

进程级别数据结构

连接到某一节点的空闲连接的集合,通过无锁队列(数组)实现
从这里拿到对应的连接,直接复用

正在使用连接池

AgentPool

typedef struct
{
    ArrayLockFreeQueue pool;
    AgentSlot* slots;
}AgentPool;

进程级别的数据结构

存放一个进程中的所有的连接

其中slots为一个数组,表明一个槽位,与pool为一一对应的状态
用于保存所有线程持有的连接,即poolAgent数据结构

AgentSlot

typedef struct
{
    int index;
    volatile AgentStatus status;
    PoolAgent* agent;
}AgentSlot;

进程级别数据结构

存放进程中的某一个连接

index与AgentPool->pool相关联

status状态为,标识该连接是否正在使用/空闲/持有

agent中为某个线程的信息(也就是每个session),都是在全局数组poolAgents中保存的

PoolAgent

typedef struct
{
    /* Agent members */
    ThreadId        pid;
    DatabasePool*   pool;
    int             index;

    /* param members */ 
    char*           user_name;
    char*           pgoptions;
    char*           paramsStr;
    char*           localParams;   /* params temporarily saved before commit */
    char*           tempNamespace; /* temp namespace name of session */
    List*           paramsList;    /* save session params, for build paramsStr */
    int             paramsReady;    /* param is set, need rebuild paramsStr */

    /* Connection members */
    int             dnNum;
    int             cnNum;
    PoolSlot**      dnConn;
    PoolSlot**      cnConn;
    NodeConnDef*    cnDef;
    NodeConnDef*    dnDef;

    /* handles members */
    NodeHandle** dnHandles;
    NodeHandle** cnHandles;
    int dnUsed;
    int cnUsed;
} PoolAgent;

对于每起一个线程session(即连接),都会有一个PoolAgent与之对应,即从DatabasePool->NodePool->pool取出来的连接

  • cnDef、dnDef:初始化时从pgxc_node中拿到,即cn定义、端口、ip
  • (session级别)dnConn、cnConn:从databasePools->nodePools-> pool拿真正对应的连接
  • (query级别)dnHandles、cnHandles:从dnConn、cnConn里边dop出来使用,确保两者是一一对应的状态,当query结束时,只需要close handles就行,cnConn不需要close

Pooler连接池具体的复用流程如下:

  1. session需要连接时,通过DB+USER为key找到正确的pooler连接池,优先从中取走现有连接,如果连接池中没有连接的话,则新建连接;
  2. query结束后,CN的postgres线程并不会归还连接,连接可以用于当前session的下一个查询;
  3. session结束后,CN的postgres线程会将连接还到对应的pooler,连接对应的DN上的postgres线程并不会退出,处于ReadCommand中,等待复用后CN新的postgres线程发起任务;

4.Pooler连接池相关的视图

pg_pooler_status视图

pg_pooler_status视图记录了pooler连接池中的所有连接信息,每一行表示本CN发起的一个连接,对应对端进程的一个postgres线程

postgres=# select * from pg_pooler_status;
 database | user_name | tid |  node_oid  |  node_name   | in_use | node_port | fdsock |   remote_pid    | session_params
----------+-----------+-----+------------+--------------+--------+-----------+--------+-----------------+----------------
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |     94 | 140259241618584 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |    101 | 140259241619432 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |     91 | 140259241618160 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |     95 | 140259241619008 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |     59 | 140259241562192 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |    106 | 140259241619856 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |    108 | 140259241620280 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |    117 | 140259241621128 | none
 postgres |   user1   |     | 2147483650 | datanode1    | f      |     37110 |    114 | 140259241620704 | none
  • in_use为‘t’表示这个连接正在某线程使用,为‘f’表示空闲连接等待复用
  • tid列为本CN的持有此连接的线程号
  • node_name列为对端进程号,remote_pid列为对端线线程号
  • 在query_id为0或CN/DN不一致时,通过pooler视图查找CN与DN连接关系

一般pooler连接池中的连接会非常多,可以按不同字段group by查看某个db pool池中的连接情况,或连往某个node的连接情况,如:

select database,user_name,node_name,in_use,count(*) from pg_pooler_status group by 1, 2, 3 ,4 order by 5 desc limit 50;

5.Pooler连接清理

清理Session持有的连接

  • cache_connection,是否使用pooler连接池缓存连接,默认开
  • session_timeout,客户端连接空闲超时后报错退出归还连接
  • enable_force_reuse_connections,事务结束后强制归还连接
  • conn_recycle_timeout(8.2.1),CN空闲session超时后归还连接

Pooler空闲连接池中的连接

  • pg_clean_free_conn视图/函数,清理1/4的空闲连接池连接,CM定期调用
  • CLEAN CONNECTION语法,清理对应DB或user的所有空闲连接 clean connection to all for database postgres to USER user1;

6.总结

本文详细介绍了Libcomm通信库及其原理,让我们更好的理解GaussDB(DWS)集群通信中的具体逻辑,对于GaussDB通信运维也具备一定的参考意义。

 

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

 

热门相关:绝代疯少   盛宠之嫡女医妃   龙组使命   总裁大人,又又又吻我了   榴绽朱门