[发明专利]一种分布式数据库节点存活状态检测模块及方法

说明书

本发明公开一种分布式数据库节点存活状态检测模块，涉及计算机通信技术领域。针对现有节点状态检测过程中存在的缺陷，将状态检测模块的监测单元监测并获取每个节点的健康状态和更新时间，将状态检测模块的处理单元按Gossip协议中的拓扑模式进行数据响应，分析和统计节点的存活状态并提取出不活跃的节点列表。本发明进一步公开一种分布式数据库节点存活状态检测方法，浪潮云海分布式数据库DRDB中，基于Gossip协议广播消息，集群中的每个节点在心跳周期内都会接收和发送包含其他节点更新消息的数据包，将前述状态检测模块与集群中的每个节点进行通信，即可提取出不活跃的节点列表。本发明可以迅速识别节点是否具有正常能力来进行副本处理、内存拷贝、消息传递等功能。

技术领域

本发明涉及计算机通信技术领域，具体的说是一种分布式数据库节点存活状态检测模块及方法。

背景技术

分布式网络中常用Raft协议来维护多个副本的一致性。参考附图1，副本总共有Leader、Follower、Candidate三种状态。其中，Leader指所有请求的处理者；Follower指请求的被动接收者，其从Leader接受更新请求，然后写入本地日志文件；Candidate指候选人，在Raft集群中，在有界时间内有且仅有一个Leader，在Leader运行正常的情况下，一个节点服务器只会属于Leader和Follower两种角色之一，直到Leader故障了，Follower才有可能变成Candidate，从而触发选举过程。

通常一个Raft组有3个副本，Leader负责和其他2个Follower进行通信，而Follower之间并不互相通信。Leader会把client的写请求log复制到Follower。它会和Follower保持心跳。每个Follower都有一个timeout时间(一般为150ms～300ms)，在接受到心跳的时候，timeout时间会被重置。也就是说每个Raft组有一个超期时间Threshold,在一个相同“纪”时间内，Follower发现Leader心跳超期时，会重新进行Raft选主操作,选出新的Leader节点后，“纪”对应的序列号增加1。

秒传递2次心跳，那N个Raft组就会传递2N/s个心跳在网络中传播，当N＝1000后，单个节点就会产生至少2000个/s心跳,如果集群中存在M个节点(M＝1000),则整个集群中就会有最少每秒上万次请求。这种请求频率，恐怕普通的集群是很难承载的。

为了解决上述超大规模的QPS(Query Per Second，每秒查询率)请求，许多厂商用了各种办法，比如：增加硬件性能、提高网卡传输带宽和速率；再比如：CockRoachDB中将多个Raft组共同上报心跳的机制修改为只去传递集群中每个节点的存活状态，这样即大大的降低了QPS的数量，但是，由于每个节点更新的时间戳一直在变，导致一个周期时间内保活消息传递的依然是整个集群中每个活跃节点的更新时间。成百上千个节点都需要自己在本地保存一份集群中其他节点的活跃状态记录表，这份记录的状态表同时也会指导各个Raft组进行后续对应的处理。这种处理虽然在一定程度上缓解了百万级请求的窘境，但每秒还是会传递数千回心跳请求。

发明内容

集群中节点处理逻辑复杂，节点自身的状态变化是不可预估的。只有正确的观察和收集节点健康状况才能持续保证集群的稳定性。传统的节点间心跳虽然可靠性高，但实际上对于一个相对稳定的系统来讲，每次传递活跃节点的心跳对于接收方来讲用途并不是很大。如果我们可以默认集群中的节点均处于正常状况，仅在非正常时进行通告，这些才是接收节点最关心的要点。基于此，本发明设计一种分布式数据库节点存活状态检测模块及方法，可以迅速识别节点是否具有正常能力来进行副本处理、内存拷贝、消息传递等功能。

首先，本发明提供一种分布式数据库节点存活状态检测模块，解决上述技术问题采用的技术方案如下：

一种分布式数据库节点存活状态检测模块，其通信连接集群中的每个节点，包括：

监测单元，用于监测并获取每个节点的健康状态和更新时间，