亚信安慧AntDB数据库分布式架构剖析之snapshot receiver进程

本文主要介绍亚信安慧AntDB数据库的分布式架构下的特有进程之 snapshot receiver的设计，这也是分布式架构的 核心进程之一。

进程简介

该进程的作用从逻辑上解释包含两个方面：

• 同步快照，并且是作为通信的client端存在

• 同步事务号，同样也是client端（ 注）

与此同时，该进程只存在于Coordinator节点（后文简称CN节点）和Datanode节点（后文简称DN节点）上，且主机和备机上都有，这些节点上有且仅有一个该进程。

（注：通信的server端则是snapshot sender进程，这部分内容笔者将会在另一篇文章中阐述）

进程的内存结构

Snapshot receiver进程在物理上并没有特别的文件存储方式，启动进程时同时会申请共享内存，所有的数据都在这部分内存之中。

内存结构名为SnapRcvData，代码内通常以SnapRcv指针来访问这部分内存，完整的结构体定义较为琐碎，为了便于读者理解，这里仅挑选部分重要的内容给出说明，完整的定义参考源码文件（src/backend/replication/snapreceiver.c）：

• mutex：访问这部分共享内存时要加的锁

• gxid_mutex：访问事务号成员时要加的锁

• geters：backend进程等待申请事务号时的队列，等待receiver进程响应申请事务号的请求

• reters：已获取事务号的backend队列，等待backend取走事务号

• xcnt：当前集群内活跃事务号的个数

• xip[MAX_BACKENDS]：当前集群内活跃事务号的列表

• wait_finish_cnt：本节点申请的事务号个数，仅CN节点会有这个值

• wait_xid_finish[MAX_BACKENDS]：本节点申请的事务号列表，仅CN节点会有这个值

• latestCompletedXid：当前集群内最大的已完成的事务号

• global_xmin：当前集群内的xmin（分布式集群内最老的活跃事务号）

• local_global_xmin：本节点内的xmin（当前节点内最老的活跃事务号）

• global_finish_id：本节点最近一次完成的事务号

进程的通信协议

“通信”特指与snapshot sender进程之间的通信，这里借用了逻辑复制的通信格式，采用了‘libpqwalreceiver’库的接口，使用到的接口的代码如下（src/backend/replication/libpqwalreceiver/libpqwalreceiver.c）：

• walrcv_connect

• walrcv_disconnect

• walrcv_startstreaming

• walrcv_send

• walrcv_receive

• walrcv_get_senderinfo

不难看出，各接口的用途与名称有一定的必然联系，首先是建连，然后开始流复制，并通过send和receive传输数据。当snapshot receiver进程启动时，会主动连接snapshot sender进程，处理过程如下图所示：

图1：snapshot receiver进程启动处理过程

建连成功之后会调用walrcv_startstreaming，把一些流复制选项同步到服务端，当服务端确认之后就会切换为copy-both模式，这时即表示可以正式传输数据了。当然，snapshot receiver进程同步的内容并不是流复制相关内容，而是事务号相关的内容，包括以下两个方面：

• 下一个待分配的事务号（nextFullXid）

• 本节点残留的2pc事务号列表，如果没有即为空（ 注）

（ 注：这部分属于进程的异常处理逻辑，笔者会在后续的文章中专题剖析 ）

建连完毕之后，进程即进入正式的通信阶段，一般来说，进入这个阶段集群基本已经启动完毕了，receiver和sender之间通过不同的消息类型去完成不同场景的需求，下面逐个介绍receiver进程的通信逻辑：

• 消息‘a’

负责处理sender进程的广播消息，消息内容是其他CN申请的事务号，其接口是SnapRcvProcessAssign，处理步骤大致如下：

1、锁住共享内存（SnapRcv）

2、从消息流获取xid，然后遍历SnapRcv->xip数组，做去重处理，然后放入该数组内，同时SnapRcv->xcnt加1

3、解锁

4、如果新的xid大于等于本地的ShmemVariableCache->nextFullXid，并且不是备节点，就需要扩展新的clog，同时更新nextFullXid

• 消息‘g’                                    

责处理申请事务号后sender进程反馈回来的数据，其接口是SnapRcvProcessAssignRequest，处理步骤大致如下：                     

1、锁住共享内存（SnapRcv）

2、从消息流获取xid和procno，然后遍历SnapRcv->reters队列，找出正在等待事务号的进程对应的procno

3、找到进程之后，xid赋值给proc->getGlobalTransaction

4、然后setlatch，通知backend进程，backend进程会取出proc->getGlobalTransaction返回给上层调用

5、解锁           

• 消息‘c’                                     

负责处理sender进程的广播消息，消息内容是其他CN结束的事务号，其接口是SnapRcvProcessComplete，处理步骤大致如下：

1、锁住共享内存（SnapRcv）

2、从消息流获取xid，然后遍历SnapRcv->xip数组，若找到就把这个xid从该数组内删除，同时SnapRcv->xcnt减1；如若没找到，会报ERROR

3、同时，如果该xid大于SnapRcv->latestCompletedXid，那就更新SnapRcv->latestCompletedXid的值

4、唤醒正在等待该事务提交的backend进程

5、解锁

6、用最新的SnapRcv->latestCompletedXid值来更新本地的ShmemVariableCache->latestCompletedXid                               

• 消息‘f ’                                   

负责处理结束事务号后sender进程反馈回来的数据，其接口是SnapRcvProcessFinishRequest，处理步骤大致如下：

1、锁住共享内存（SnapRcv）

2、从消息流获取xid和procno，然后遍历SnapRcv->wait_commiters队列，找出正在等待的进程对应的procno和xid

3、找到进程之后，proc->getGlobalTransaction的值恢复为InvalidTransactionId

4、然后setlatch，通知backend进程

5、解锁

• 消息‘s’                                     

负责处理sender进程同步来的快照数据，其接口是SnapRcvProcessSnapshot，处理步骤大致如下：

1、从消息流获取快照、xmin和latestCompletedXid三份数据

2、锁住共享内存（SnapRcv）

3、用gtm传来的值更新SnapRcv->latestCompletedXid

4、把快照数据整体memcpy到SnapRcv->xip数组

5、唤醒等待中的进程

6、解锁

7、更新SnapRcv->global_xmin（这个值在backend获取快照时，用于更新snapshot->global_xmin）

• 消息‘h’                                    

处理心跳消息的反馈，其接口是SnapRcvProcessHeartBeat，处理步骤大致如下：

1、接收的心跳包内包含2个内容，时间戳和xmin

2、接收到心跳之后，更新SnapRcv->gtm_delta_time和SnapRcv->global_xmin

相对应的，还有一个发送心跳包的接口为SnapRcvSendHeartbeat，这个并不是‘h’消息的处理内容，而是SnapReceiverMain主函数的流程，处理步骤大致如下：

1、每次循环到对应的处理阶段（参考图2的流程），判断当前时间是否超过了设定的心跳间隔时间阈值（snap_receiver_timeout），这个是guc参数，默认60s 

2、 如果超过了阈值，就发送心跳包，否则跳过

3、发送的内容同接收一样，时间戳和xmin

消息‘u’                                    

sender进程会通过这个消息，把nextFullXid同步到所有其他节点，其接口是SnapRcvProcessUpdateXid，处理步骤如下：

1、sender发来的只有一个事务号，即nextFullXid（下一个待分配的事务号）

2、如果拿到的xid比本地ShmemVariableCache->nextFullXid的要大，就更新ShmemVariableCache->nextFullXid和ShmemVariableCache->latestCompletedXid

3、最后更新SnapRcv->latestCompletedXid（先锁后更新）

进程的工作主流程

Snapshot receiver进程整体上同其他辅助进程相类似，启动之后会处于一个无限循环之中，不断监听各种事件和信号，笔者整理了一份流程图帮助读者理解，如下图所示：

图 2：Snapshot receiver进程工作主流程图

上述流程图对应的既是SnapReceiverMain函数，又是snapshot receiver进程的主函数，之前的各种消息处理都是从这里开始的，想深入理解各种细节的读者可以从这里入手。

小结

本文介绍了snapshot receiver进程在正常情况下的处理逻辑，通过流复制协议，配合以不同的消息处理函数，完成了分布式事务号、分布式快照的同步功能。一个进程不可能总是处于正常状态，那当异常发生时，AntDB如何来保证事务的一致性呢？敬待后续的专题分享。

关于亚信安慧AntDB数据库

AntDB数据库始于2008年，在运营商的核心系统上，服务国内24个省市自治区的数亿用户，具备高性能、弹性扩展、高可靠等产品特性，峰值每秒可处理百万笔通信核心交易，保障系统持续稳定运行超十年，并在通信、金融、交通、能源、物联网等行业成功商用落地。