CN115277718A - 一种基于节点状态信息的共识方法和分布式系统 - Google Patents

Abstract

本发明公开了一种基于节点状态信息的共识方法和分布式系统，前者包括：领导者节点以预设周期向各跟随者节点发送添加有领导者节点的状态信息的请求报文；各跟随者节点在接收到的请求报文含有日志条目时，在复制日志信息后基于该请求报文中的状态信息，判断领导者节点的状态是否满足预设要求，从而确定针对领导者节点的投票信息为赞成票或反对票；各跟随者节点将投票信息添加在响应报文中将完成的响应报文发送给领导者节点；领导者节点统计接收到的响应报文中反对票的数目是否超过预设数目；若超过，领导者节点主动转变为跟随者节点，以使得分布式系统等待新的节点超时并重新选举领导者节点。本发明能提升系统运行时的安全性和稳定性。

Description

一种基于节点状态信息的共识方法和分布式系统

技术领域

本发明属于分布式系统领域，具体涉及一种基于节点状态信息的共识方法和分布式系统。

背景技术

在一个分布式系统中，如何保证集群中所有节点中的数据完全相同并且能够对某个提案(Proposal)达成一致，是分布式系统正常工作的核心问题，而共识算法就是用来保证分布式系统一致性的方法。目前，Raft是比较常用的一种共识算法。Raft集群包含多个作为节点的服务器，在任何给定时间，每个服务器都处于以下三种状态之一：领导者(Leader)、跟随者(Follower)或候选者(Candidate)，这几个状态之间可以相互转换。Raft算法将一致性问题分解为两个子问题，领导者选举和状态复制，具体使用一种心跳机制来触发领导者选举。

分析Raft算法的选举流程可以发现，其存在着系统性能不稳定和中心化程度过高等可靠性和安全性问题，原因在于Raft算法并没有考虑集群正常启动后的稳定性问题，当集群中大多数节点尤其是领导者节点持续稳定运行时，系统中很少出现节点宕机的情况，也没有节点因网络分区而离线。此时会出现因为服务器自身负载的上升，引起领导者节点日志复制效率低下的问题。

具体的，Raft算法是一种强领导性的共识算法，即领导者节点处理集群收到的所有写入业务请求和日志复制工作，领导者节点的选举首先通过超时机制随机地选出候选者，候选者在集群中广播投票消息，若候选者收到集群中一半以上数量节点回复的支持投票则将身份转换为领导者，Raft算法只有在领导者节点崩溃宕机或网络分区离线时才会触发新一轮的选举过程。由于领导者节点承担了系统内全部的日志复制工作，同时还需要周期性地向跟随者节点发送心跳信息来通知自己的状态，因此当集群中节点数量持续增加时，领导者节点的工作量也随之增大。在一个集群中，各个节点的性能和稳定程度会有一定的差异，为了实现更好的效果，原则上领导者节点应该是集群中性能最优且稳定的节点，然而Raft算法为了方便使用者更好地理解和实现，其并未在节点选举过程中增加太多限制，也没有考虑集群正常启动后的稳定性问题。因而当集群中大多数节点尤其是领导者节点长期运行在正常情况下时，除非发生意外情况使其离线或崩溃，否则不会主动更换领导者节点，即使在服务器性能受到外部因素影响而降低的情况下也是如此，那么无疑进一步使得整个集群内部的日志复制效率变差。

同时，Raft算法是一种实现高可用性副本的一致性算法，核心目的是为了解决分布式系统中各节点上存储日志副本一致性的问题，由于Raft算法中，除非发生系统崩溃离线导致无法继续发送心跳信息等异常情况，一般在领导者节点任命后是不会主动更换领导者节点的。这种选举机制也会使得系统整体的中心化程度过高，算法的应用场景局限于较为中心化的分布式网络，在一些不存在拜占庭节点的联盟链中则不可用。

发明内容

本发明实施例的目的在于提供一种基于节点状态信息的共识方法和分布式系统，以实现提升分布式系统运行时的安全性和稳定性的目的。具体技术方案如下：

第一方面，本发明实施例提供了一种基于节点状态信息的共识方法，应用于包括一个领导者节点和多个跟随者节点在内的分布式系统中，所述方法包括：

所述领导者节点以预设周期向各跟随者节点发送添加有所述领导者节点的状态信息的请求报文；其中，所述状态信息含有所述领导者节点的性能和安全性指标；

各跟随者节点在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，并根据判断结果确定针对所述领导者节点的投票信息；其中，若判定所述领导者节点的状态满足预设要求，投票信息为赞成票，反之为反对票；

各跟随者节点将确定的投票信息添加在响应报文中，并将完成的响应报文发送给所述领导者节点；

所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过预设数目；

若超过，所述领导者节点主动转变为跟随者节点，以使得所述分布式系统等待新的节点超时并重新选举领导者节点。

在本发明的一个实施例中，所述状态信息包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

在本发明的一个实施例中，所述基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，包括：

每个跟随者节点，判断所述领导者节点的吞吐量是否低于预设的吞吐量阈值；

判断所述共识次数是否高于预设的共识次数阈值；

判断所述共识时延是否高于预设的共识时延阈值；

根据该跟随者节点接收到所述目标请求报文的时间，与所述目标请求报文携带的请求报文发出时间戳，计算所述领导者节点与该跟随者节点间的网络时延，并判断所述网络时延的变化量是否大于预设的网络时延变化量阈值；其中，所述网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值；

根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求。

在本发明的一个实施例中，所述根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求，包括：

若至少有一项状态信息的判断结果为是，则判定所述领导者节点的状态不满足预设要求；若各项状态信息的判断结果均为否，则判定所述领导者节点的状态满足预设要求。

在本发明的一个实施例中，所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过预设数目，包括：

所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过所述分布式系统中节点总数的半数。

在本发明的一个实施例中，所述方法还包括：

各跟随者节点在接收到的请求报文不含有日志条目时，默认所述领导者节点的状态满足预设要求，确定针对所述领导者节点的投票信息为赞成票。

在本发明的一个实施例中，所述方法还包括：

若所述领导者节点统计接收到的响应报文中所述反对票的数目未超过预设数目，所述领导者节点维持当前领导者状态。

第二方面，本发明实施例提供了一种分布式系统，包括一个领导者节点和多个跟随者节点，其中：

所述领导者节点，用于以预设周期向各跟随者节点发送添加有所述领导者节点的状态信息的请求报文；其中，所述状态信息含有所述领导者节点的性能和安全性指标；

各跟随者节点，用于在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，并根据判断结果确定针对所述领导者节点的投票信息；其中，若判定所述领导者节点的状态满足预设要求，投票信息为赞成票，反之为反对票；将确定的投票信息添加在响应报文中，并将完成的响应报文发送给所述领导者节点；

所述领导者节点，还用于统计接收到的响应报文中所述反对票的数目是否超过预设数目；若超过，主动转变为跟随者节点，以使得所述分布式系统等待新的节点超时并重新选举领导者节点。

在本发明的一个实施例中，所述状态信息包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

在本发明的一个实施例中，各跟随者节点在基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求时，具体用于：

判断所述领导者节点的吞吐量是否低于预设的吞吐量阈值；

判断所述共识次数是否高于预设的共识次数阈值；

判断所述共识时延是否高于预设的共识时延阈值；

根据该跟随者节点接收到所述目标请求报文的时间，与所述目标请求报文携带的请求报文发出时间戳，计算所述领导者节点与该跟随者节点间的网络时延，并判断所述网络时延的变化量是否大于预设的网络时延变化量阈值；其中，所述网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值；

根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求。

本发明的有益效果：

本发明实施例所提供的基于节点状态信息的共识方法中，对领导者节点向其余节点发送的请求报文进行了修改，增加了表征领导者节点性能和安全性指标的状态信息，并在请求报文含有日志条目时，触发接收到请求报文的各跟随者节点的主动重新选举机制，使得各跟随者节点在复制完日志信息后，根据请求报文中的状态信息判断领导者节点的状态是否满足预设要求，并据此在反馈给领导者节点的响应报文中添加对应的投票信息为赞成票或者反对票。领导者节点在统计到反对票的数目超过预设数目时会主动转变为跟随者节点，分布式系统会重新进行领导者节点的选举。可见，本发明实施例相比于现有技术，通过在领导者节点的请求报文中添加领导者节点的状态信息，并在跟随者节点的报文处理算法中添加与之对应的投票策略，对在任领导者节点进行性能和安全性评估并在其不满足要求时投票使其下台，以重新选举合适的领导者节点，因而能够提升系统运行时的安全性和稳定性。

附图说明

图1为本发明实施例所提供的基于节点状态信息的共识方法的一种流程示意图；

图2为本发明实施例所提供的基于节点状态信息的共识方法的另一种流程示意图；

图3为本发明实施例所提供的分布式系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了提升分布式系统运行时的安全性和稳定性，本发明实施例提供了一种基于节点状态信息的共识方法和分布式系统。

第一方面，本发明实施例提供了一种基于节点状态信息的共识方法，应用于包括一个领导者节点和多个跟随者节点在内的分布式系统中，如图1所示，该方法包括：

S1，领导者节点以预设周期向各跟随者节点发送添加有领导者节点的状态信息的请求报文。

本领域技术人员已知的是，Raft算法在完成第一轮选举进入正常运行状态后，节点间的交互通过Append Entries协议完成，领导者节点定期向跟随者节点发送AppendEntries RPC请求报文，一方面是作为心跳信息，告知跟随者节点自己的状态信息，巩固领导者节点的身份状态，同时也可以利用跟随者节点反馈的Append Entries RPC响应报文掌握跟随者节点的工作情况；另一方面是发送待复制的日志数据给集群内的跟随者节点。其中，预设周期可以根据需要设置，比如可以为10毫秒等。

具体的，当Append Entries RPC请求报文中的entries域，也就是日志条目为空时，该Append Entries RPC请求报文作为领导者节点的心跳包；当entries域不为空时，领导者节点请求其他节点将entries域中的log(需要被保存的日志条目)添加到自己的log中，即要求其余节点进行日志信息复制处理。

考虑到各个节点的性能差异，本发明实施例为了实现更好的系统性能，对现有Raft算法进行改进，期望对在任的领导者节点的性能进行衡量，以在其性能不满足要求时迫使其下台，引发新的领导者节点选举，因此，首先需要收集在任的领导者节点的性能状况。为此，在现有Append Entries RPC请求报文基础上添加领导者节点的状态信息。

本发明实施例中的状态信息含有领导者节点的性能和安全性指标，用于衡量领导者节点的计算能力、计算效率以及安全性等。比如，可选的一种实施方式中，状态信息可以包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

其中，领导者节点的吞吐量表示单位时间内成功地传送数据的数量。领导者节点的共识次数表示领导者节点处理写入业务的累计次数。领导者节点的共识时延表示分布式系统处理一次写入请求的总耗时，包括将日志复制到集群内所有节点上的耗时。请求报文发出时间戳表示领导者节点发出请求报文的时间，用来计算节点间的网络时延，进一步计算其变化量。

为了便于理解，请参见表1理解本发明实施例的添加有领导者节点的状态信息的请求报文，表1中的本发明实施例的请求报文表示一种改进的Append Entries RPC请求报文。

表1本发明实施例的请求报文

本发明实施例的请求报文中，包含有现有Append Entries RPC请求报文中的数据信息，即领导者节点的Id编号“leaderId”、领导者节点的任期“term”、紧邻新日志条目之前的那个日志条目的序号“prevLogIndex”、紧邻新日志条目之前的那个日志条目的任期“prevLogTerm”、领导者节点的最新日志序号“leaderCommit”和需要被保存的日志条目“entries[]”，其中，“entries[]”的内容表示待写入的日志数据，在该请求报文表示心跳信息时，“entries[]”内容为空。关于这几项请结合现有Append Entries RPC请求报文的数据内容理解，在此不做过多解释。

本发明实施例对现有Append Entries RPC请求报文新增的领导者节点的吞吐量、领导者节点的记账次数、领导者节点的共识时延和请求报文发出时间戳，分别以tps、setCount、dealTime和sendTime对应表示。

S2，各跟随者节点在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的状态信息，判断领导者节点的状态是否满足预设要求，并根据判断结果确定针对领导者节点的投票信息。

本发明实施例通过修改Append Entries RPC请求报文内通信数据的方式来让分布式系统中的节点集群内，各跟随者节点对领导者节点的性能进行投票，以使得各跟随者节点执行针对领导者节点的主动重新选举机制的判断策略。

出于对系统通信开销的考虑，各跟随者节点若在Append Entries RPC请求报文的心跳阶段处理主动重新选举机制的判断策略，则各跟随者节点在正常运行过程的每次心跳请求中都会对主动重新选举机制中添加的领导者节点状态信息进行相关的计算以及判断，会大大增加整个系统的通信开销，不适合应用于实际生产环境。同时，由于Append EntriesRPC请求报文的另一个作用是将操作日志记录同步给所有跟随者节点，因此，在跟随者节点进行日志复制操作完成之后再对领导者节点执行主动重新选举机制的判断策略，将会减少大量的通信开销，能够增加在实际生产环境中应用的可行性。

具体的，针对每一个跟随者节点，在每次接收到请求报文后，对请求报文中是否包含日志条目进行判断，如果包含，则根据该日志条目复制日志信息，之后，除了按照对现有Append Entries RPC请求报文的处理逻辑进行处理之外，还基于接收到的含有日志条目的请求报文中的状态信息，判断领导者节点的状态是否满足预设要求，以确定投票信息为赞成票还是反对票。

其中，若判定领导者节点的状态满足预设要求，投票信息为赞成票，反之为反对票。

可选的一种实施方式中，基于该请求报文中的状态信息，判断领导者节点的状态是否满足预设要求，可以包括：

1)每个跟随者节点，判断领导者节点的吞吐量是否低于预设的吞吐量阈值。

2)判断共识次数是否高于预设的共识次数阈值。

3)判断共识时延是否高于预设的共识时延阈值。

4)根据该跟随者节点接收到目标请求报文的时间，与目标请求报文携带的请求报文发出时间戳，计算领导者节点与该跟随者节点间的网络时延，并判断网络时延的变化量是否大于预设的网络时延变化量阈值；其中，网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值。

5)根据各项状态信息的判断结果，利用预设的判断策略判断领导者节点的状态是否满足预设要求。

其中，预设的吞吐量阈值、预设的共识次数阈值、预设的共识时延阈值和预设的网络时延变化量阈值是本发明实施例预先根据实验数据设置的，具体数值可以根据需要调整。比如，可选的一种实施方式中，预设的吞吐量阈值、预设的共识次数阈值、预设的共识时延阈值和预设的网络时延变化量阈值可以分别为：150次/秒、10000次、50毫秒、±200毫秒等。

本领域技术人员可以理解的是，领导者节点的吞吐量低于预设的吞吐量阈值说明领导者节点传输数据量和业务处理能力较差；共识次数高于预设的共识次数阈值说明该领导者节点已进行了多次共识，影响分布式系统安全性；共识时延高于预设的共识时延阈值，以及网络时延的变化量是否大于预设的网络时延变化量阈值说明领导者节点在数据传输的实时性、稳定性和安全性上较差。上述各项均能够体现当前在任的领导者节点的性能已经不适合继续担任分布式系统的领导者的角色。

根据上述步骤1)～4)，可以得到四项状态信息的判断结果。本发明实施例可以根据需要选择合适的预设的判断策略，利用这四项状态信息的判断结果来确定领导者节点的性能是否满足预设要求。

比如，可选的一种实施方式中，根据各项状态信息的判断结果，利用预设的判断策略判断领导者节点的状态是否满足预设要求，可以包括：

若至少有一项状态信息的判断结果为是，则判定领导者节点的状态不满足预设要求；若各项状态信息的判断结果均为否，则判定领导者节点的状态满足预设要求。

可以理解的是，该种判断策略是较为严格的优选实施方式，当然，也可以根据实际情况选择较为宽松的判断策略，比如进行上述1)-4)的判断之后，可选的另一种实施方式中，可以是：若有三项状态信息的判断结果为是，则判定领导者节点的状态不满足预设要求；若有三项状态信息的判断结果为否，则判定领导者节点的状态满足预设要求。

同时，本发明实施例的方法还包括：

各跟随者节点在接收到的请求报文不含有日志条目时，默认领导者节点的状态满足预设要求，确定针对领导者节点的投票信息为赞成票。也就是说，如果各跟随者节点在接收到的请求报文不含有日志条目时，不复制日志信息，也不对相应请求报文中的状态信息进行计算和判断处理，即不执行针对领导者节点的主动重新选举机制的判断策略，直接默认针对领导者节点的投票信息为赞成票。

S3，各跟随者节点将确定的投票信息添加在响应报文中，并将完成的响应报文发送给领导者节点。

以下结合本发明实施例的响应报文的具体内容，具体说明各跟随者节点对接收到的请求报文的处理逻辑。请参见表2，表2中的本发明实施例的响应报文表示一种改进的Append Entries RPC响应报文。

表2本发明实施例的响应报文

本发明实施例的响应报文中，包含有现有Append Entries RPC响应报文中的数据信息，即跟随者节点根据自身条目与领导者节点匹配与否反馈的信息值“success”以及跟随者节点的当前任期“term”。关于这两项内容请参见现有技术理解，在此不做详细说明。

本发明实施例对现有Append Entries RPC响应报文新增的给在任领导者节点的投票信息以“granted”表示。

为了便于理解跟随者节点接收到领导者节点发送来的含有日志条目发请求报文后的处理逻辑，在此对接收到请求报文的每个跟随者节点的处理过程进行简要说明，主要包括以下步骤：

①比较请求报文携带的领导者节点的任期term和自身的任期term，若领导者节点的任期term小于自身的任期term，则将success置为false。

②在自身日志中如果能找到一个和请求报文中prevLogIndex一样的索引以及和prevLogTerm一样任期的日志条目，则继续执行下面的步骤，否则将success置为false。

③如果自身的日志序号和请求报文中领导者节点的最新日志序号leaderCommit冲突，则删除自身冲突日志及后续的所有日志记录。

④追加日志中尚未存在的任何新条目entries，即根据entries中的日志条目复制日志信息。

⑤如果领导者节点当前已提交的最新日志序号大于跟随者节点自身的最新日志序号，则更新跟随者节点自身的最新日志序号leaderCommit为领导者节点的最新日志序号。

⑥基于请求报文中的状态信息，判断领导者节点的状态是否满足预设要求，若不满足，将granted值设定为false；若满足，将granted值设定为true。

本领域技术人员可以理解的是，上述①～⑤是传统Raft共识算法中跟随者节点接收到现有Append Entries请求报文后的处理逻辑，请结合相关现有技术理解，在此不做详细说明。

可以理解的是，本发明实施例中，领导者节点发出的请求报文中，若不含有日志条目，各跟随者节点针对该请求报文，执行上述①～⑤，在执行⑥时，将反馈的响应报文中投票信息默认为赞成票“granted＝true”；若含有日志条目，各跟随者节点针对该请求报文，执行上述①～⑤，在执行⑥时，反馈的响应报文中投票信息是跟随者节点根据请求报文中领导者节点的状态信息确定的。

S4，领导者节点统计接收到的响应报文中反对票的数目是否超过预设数目。

本发明实施例中，领导者节点可以对接收到的响应报文中反对票的数目进行累计计数，以根据反对票的数目是否超过预设数目，来确定自身的领导者状态是否需要更改。

可以根据不同分布式系统中服务器的通常数量范围情况，预先设置一个通用固定的预设数目，比如分布式系统中服务器数量若在100～200个，可以设置一个预设数目为60等。

当然，也可以根据当前所属的分布式系统中服务器的具体数目来确定预设数目，比如，可选的一种实施方式中，领导者节点统计接收到的响应报文中反对票的数目是否超过预设数目，包括：

领导者节点统计接收到的响应报文中反对票的数目是否超过分布式系统中节点总数的半数。

本领域技术人员可以理解的是，领导者节点已知所在的分布式系统中的节点总数，若反对票的数目超过分布式系统中节点总数的半数，表明大多数跟随者节点对在任的领导者节点持反对意见，那么领导者节点需要据此改变自身的领导者状态。

若超过，执行S5，领导者节点主动转变为跟随者节点，以使得分布式系统等待新的节点超时并重新选举领导者节点。

可见，本发明实施例可以主动触发领导者节点的更换过程，通过投票使不符合性能和安全性需求的领导者节点下台，以重新选举新的领导者节点。在领导者节点主动转变为跟随者节点后，分布式系统中所有节点均为跟随者状态，可以利用现有的选举机制再次选举出一个领导者节点。关于新的领导者节点的选举过程请参见现有Raft算法，在此不做详细说明。

可以理解的是，若领导者节点统计接收到的响应报文中反对票的数目未超过预设数目，领导者节点维持当前领导者状态。也就是说，此时在任的领导者节点继续担任领导者。

本发明实施例所提供的基于节点状态信息的共识方法中，对领导者节点向其余节点发送的请求报文进行了修改，增加了表征领导者节点性能和安全性指标的状态信息，并在请求报文含有日志条目时，触发接收到请求报文的各跟随者节点的主动重新选举机制，使得各跟随者节点在复制完日志信息后，根据请求报文中的状态信息判断领导者节点的状态是否满足预设要求，并据此在反馈给领导者节点的响应报文中添加对应的投票信息为赞成票或者反对票。领导者节点在统计到反对票的数目超过预设数目时会主动转变为跟随者节点，分布式系统会重新进行领导者节点的选举。可见，本发明实施例相比于现有技术，通过在领导者节点的请求报文中添加领导者节点的状态信息，并在跟随者节点的报文处理算法中添加与之对应的投票策略，对在任领导者节点进行性能和安全性评估并在其不满足要求时投票使其下台，以重新选举合适的领导者节点，因而能够提升系统运行时的安全性和稳定性。

以下，请参考图2理解本发明实施例的基于节点状态信息的共识方法的完整过程。

在分布式系统启动并按照现有方法选出第一位领导者节点后，领导者节点开始周期性地向所有跟随者节点发送本发明实施例改进的Append Entries RPC请求报文，该请求报文中添加有领导者节点的状态信息，包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。该请求报文作为心跳信息，通知所有跟随者节点以维持自己的领导者权力。

为了节约通信开销，本发明实施例不会在每次请求报文后均触发主动重新选举流程，只有当请求报文含有日志条目时，跟随者节点完成日志复制流程后，才触发针对领导者节点的主动重新选举流程，此时跟随者节点判断请求报文中状态信息携带的领导者节点的吞吐量、共识次数、共识时延和根据请求报文发出时间戳计算得到的网络时延的变化量与各自对应阈值的大小关系，若至少有一项性能信息的判断结果为是，则判定领导者节点的性能不满足预设要求，将现有的Append Entries RPC响应报文增加granted项，且将granted置为false，即投出反对票；若各项性能信息的判断结果均为否，则判定领导者节点的性能满足预设要求，将本发明实施例的响应报文中的granted置为true，即投出赞成票。领导者节点统计收到的Append Entries RPC响应报文中的反对票数目，若收到的反对票后的数目超过分布式系统中节点总数的半数，则主动下台并增加任期，开启新一轮的选举。

并且，本发明实施例中，为了减小数据存储压力，节点不对新增加领导者节点的四项状态信息进行持久化存储，领导者节点下台后将其重置为零。

以下以五个服务器A1～A5构成的分布式系统的集群为例说明，并保证集群正常运行，不存在参与者离线或崩溃等异常。系统运行后所有参与者均为跟随者状态且状态信息为初始化值。

系统启动后，集群中所有节点身份均为跟随者，进入领导者选举流程，以A1为例，其率先发生心跳消息超时，即达到超时时间，则A1的节点状态转换为候选者，同时A1广播发送RequestVote RPC报文请求投票，当候选者收到半数以上同意选票后A1转变为领导者状态，系统进入正常工作状态。

随着领导者节点不断地处理写入业务，其吞吐量、共识时延和其与跟随者节点间的网络时延稳定性信息逐渐递增并维持在一个稳定的数值，共识请求次数信息线性递增。在领导者节点向其他节点发送的请求报文中添加当前领导者节点A1的状态信息，当A1节点出现以下4种情况之一时，领导者节点会在响应报文中收到granted值为false的反对投票，当收到的反对票的数目超过半数节点总数后，领导者节点A1主动下台变为跟随者，进入下一轮选举，此时分布式系统中的所有节点均为跟随者节点，当存在一个跟随者节点的选举超时时间达到时，其状态转变为候选者节点，并广播投票请求以选出新的领导者节点，同样的，针对新上台的领导者节点，重复本发明实施例的基于节点状态信息的共识方法。

其中，上述4种情况分别为：

1)A1节点因系统负载原因导致吞吐量持续维持在较低的水平，低于预设的吞吐量阈值。

2)A 1节点共识次数已经逐渐增长到超出预设的共识次数阈值。

3)A1节点的共识时延超出预设的共识时延阈值。

4)A 1节点到当前收到请求报文的跟随者节点间的网络时延的变化量，即网络时延抖动，超出预设的网络时延变化量阈值。

可见，本发明实施例改进了现有Raft算法的选举投票策略，通过在心跳消息中添加领导者节点的状态信息，在跟随者节点收到包含日志条目的心跳消息并完成日志复制操作后触发主动重新选举机制。使得跟随者节点对领导者节点的状态信息进行衡量后，在领导者节点的状态信息满足预设要求时在响应报文中添加赞成票，在领导者节点的状态信息不满足预设要求时在响应报文中添加反对票，能够迫使不满足性能和安全性等要求的领导者节点主动下台，启动新的领导者选举流程。因此，能够使得分布式系统有着更高的吞吐量、安全性、一致性和活性，解决系统运行时的性能下降等问题。

第二方面，相应于上述方法实施例，本发明实施例还提供了一种分布式系统，如图3所示，该分布式系统包括一个领导者节点和多个跟随者节点，其中：

领导者节点，用于以预设周期向各跟随者节点发送添加有领导者节点的性能信息的请求报文。

各跟随者节点，用于在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的性能信息，判断领导者节点的性能是否满足预设要求，并根据判断结果确定针对领导者节点的投票信息；其中，若判定领导者节点的性能满足预设要求，投票信息为赞成票，反之为反对票；将确定的投票信息添加在响应报文中，并将完成的响应报文发送给领导者节点。

领导者节点，还用于统计接收到的响应报文中反对票的数目是否超过预设数目；若超过，主动转变为跟随者节点，以使得分布式系统等待新的节点超时并重新选举领导者节点。

可选的，性能信息包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

可选的，各跟随者节点在基于该请求报文中的性能信息，判断领导者节点的性能是否满足预设要求时，具体用于：

判断领导者节点的吞吐量是否低于预设的吞吐量阈值。

判断共识次数是否高于预设的共识次数阈值。

判断共识时延是否高于预设的共识时延阈值。

根据该跟随者节点接收到目标请求报文的时间，与目标请求报文携带的请求报文发出时间戳，计算领导者节点与该跟随者节点间的网络时延，并判断网络时延的变化量是否大于预设的网络时延变化量阈值；其中，网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值。

根据各项性能信息的判断结果，利用预设的判断策略判断领导者节点的性能是否满足预设要求。

可选的，各跟随者节点在根据各项性能信息的判断结果，利用预设的判断策略判断领导者节点的性能是否满足预设要求时，具体用于：

若至少有一项性能信息的判断结果为是，则判定领导者节点的性能不满足预设要求；若各项性能信息的判断结果均为否，则判定领导者节点的性能满足预设要求。

可选的，领导者节点统计接收到的响应报文中反对票的数目是否超过预设数目的方式，具体包括：

领导者节点统计接收到的响应报文中反对票的数目是否超过分布式系统中节点总数的半数。

可选的，各跟随者节点还用于：

各跟随者节点在接收到的请求报文不含有日志条目时，默认领导者节点的性能满足预设要求，确定针对领导者节点的投票信息为赞成票。

可选的，领导者节点还用于：

若领导者节点统计接收到的响应报文中反对票的数目未超过预设数目，领导者节点维持当前领导者状态。

具体内容请参见第一方面所描述的内容，在此不做赘述。

本发明实施例提供的分布式系统，通过在领导者节点的请求报文中添加领导者节点的状态信息，并在跟随者节点的报文处理算法中添加与之对应的投票策略，对在任领导者节点进行性能和安全性评估并在其不满足要求时投票使其下台，以重新选举合适的领导者节点，因而能够提升系统运行时的安全性和稳定性。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。此外，本领域的技术人员可以将本说明书中描述的不同实施例或示例进行接合和组合。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种基于节点状态信息的共识方法，其特征在于，应用于包括一个领导者节点和多个跟随者节点在内的分布式系统中，所述方法包括：

所述领导者节点以预设周期向各跟随者节点发送添加有所述领导者节点的状态信息的请求报文；其中，所述状态信息含有所述领导者节点的性能和安全性指标；

各跟随者节点在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，并根据判断结果确定针对所述领导者节点的投票信息；其中，若判定所述领导者节点的状态满足预设要求，投票信息为赞成票，反之为反对票；

各跟随者节点将确定的投票信息添加在响应报文中，并将完成的响应报文发送给所述领导者节点；

所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过预设数目；

若超过，所述领导者节点主动转变为跟随者节点，以使得所述分布式系统等待新的节点超时并重新选举领导者节点。

2.根据权利要求1所述的基于节点状态信息的共识方法，其特征在于，所述状态信息包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

3.根据权利要求2所述的基于节点状态信息的共识方法，其特征在于，所述基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，包括：

每个跟随者节点，判断所述领导者节点的吞吐量是否低于预设的吞吐量阈值；

判断所述共识次数是否高于预设的共识次数阈值；

判断所述共识时延是否高于预设的共识时延阈值；

根据该跟随者节点接收到所述目标请求报文的时间，与所述目标请求报文携带的请求报文发出时间戳，计算所述领导者节点与该跟随者节点间的网络时延，并判断所述网络时延的变化量是否大于预设的网络时延变化量阈值；其中，所述网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值；

根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求。

4.根据权利要求3所述的基于节点状态信息的共识方法，其特征在于，所述根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求，包括：

若至少有一项状态信息的判断结果为是，则判定所述领导者节点的状态不满足预设要求；若各项状态信息的判断结果均为否，则判定所述领导者节点的状态满足预设要求。

5.根据权利要求1所述的基于节点状态信息的共识方法，其特征在于，所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过预设数目，包括：

所述领导者节点统计接收到的响应报文中所述反对票的数目是否超过所述分布式系统中节点总数的半数。

6.根据权利要求1所述的基于节点状态信息的共识方法，其特征在于，所述方法还包括：

各跟随者节点在接收到的请求报文不含有日志条目时，默认所述领导者节点的状态满足预设要求，确定针对所述领导者节点的投票信息为赞成票。

7.根据权利要求1或5所述的基于节点状态信息的共识方法，其特征在于，所述方法还包括：

若所述领导者节点统计接收到的响应报文中所述反对票的数目未超过预设数目，所述领导者节点维持当前领导者状态。

8.一种分布式系统，其特征在于，包括一个领导者节点和多个跟随者节点，其中：

所述领导者节点，用于以预设周期向各跟随者节点发送添加有所述领导者节点的状态信息的请求报文；其中，所述状态信息含有所述领导者节点的性能和安全性指标；

各跟随者节点，用于在接收到的请求报文含有日志条目时，在复制日志信息后，基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求，并根据判断结果确定针对所述领导者节点的投票信息；其中，若判定所述领导者节点的状态满足预设要求，投票信息为赞成票，反之为反对票；将确定的投票信息添加在响应报文中，并将完成的响应报文发送给所述领导者节点；

所述领导者节点，还用于统计接收到的响应报文中所述反对票的数目是否超过预设数目；若超过，主动转变为跟随者节点，以使得所述分布式系统等待新的节点超时并重新选举领导者节点。

9.根据权利要求8所述的分布式系统，其特征在于，所述状态信息包括领导者节点的吞吐量、共识次数、共识时延和请求报文发出时间戳。

10.根据权利要求8所述的分布式系统，其特征在于，各跟随者节点在基于该请求报文中的状态信息，判断所述领导者节点的状态是否满足预设要求时，具体用于：

判断所述领导者节点的吞吐量是否低于预设的吞吐量阈值；

判断所述共识次数是否高于预设的共识次数阈值；

判断所述共识时延是否高于预设的共识时延阈值；

根据该跟随者节点接收到所述目标请求报文的时间，与所述目标请求报文携带的请求报文发出时间戳，计算所述领导者节点与该跟随者节点间的网络时延，并判断所述网络时延的变化量是否大于预设的网络时延变化量阈值；其中，所述网络时延的变化量表示当前计算得到的网络时延与上一次计算得到的网络时延的差值；

根据各项状态信息的判断结果，利用预设的判断策略判断所述领导者节点的状态是否满足预设要求。

Images