CN115051913A - Raft配置变更方法和装置 - Google Patents

Abstract

本申请涉及一种Raft配置变更方法和装置，其中，该Raft配置变更方法应用于Raft集群中的所有节点，包括：节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；在集群中的节点个数为两个的情况下，该节点提交日志，通过本申请，解决了相关技术中采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题，提高了系统的运行的安全性和稳定性。

Description

Raft配置变更方法和装置

技术领域

本申请涉及分布式系统技术领域，特别是涉及一种Raft配置变更方法和装置。

背景技术

Raft是一种广泛使用的分布式共识算法，一个Raft集群包含多个分布式节点，节点之间通过RPC通信。Raft节点通过选举产生一个主节点，然后由主节点负责提交并复制日志到其他节点上。Raft是一种多数派读、写算法，日志的读、写操作只要经过半数以上节点确认即可成功提交，多数派的读写也意味着只要集群里还有过半数的节点能通信就能正常提供服务。

Raft配置变更是指，在不停机的情况下调整Raft集群的节点（例如往集群添加或删除若干节点），在此过程中，需要保证算法运行的正确性——副本数据的一致性。Raft为了保证配置变更进行过程的高可用（服务不停机）和安全性（副本数据一致性），把配置变更也实现为一个共识达成的过程——既通过提交一条代表配置变更操作的日志。在相关技术中，配置变更方式主要有两种，一种是“apply before commit（先应用，后提交）”，另一种是“apply after commit（先提交，后应用）”。通常一条Raft日志需要提交后才能apply，“apply before commit”是指配置变更操作被特殊处理，将其作为一条特殊的Raft log提交，从而在提交前即可apply；而“apply after commit”则是配置变更日志成功提交后才apply这条日志。

Raft可能会出现日志回滚的情况，当一条日志尚未复制到过半数节点，此时如果发生主节点切换，那么新的主节点可能会提交一条日志覆盖尚未提交的日志，Raft采用“apply before commit”方式的配置变更有存在至少两个明显的问题：首先，需要检查每条准备提交的日志是否需要被特殊处理，这带来了额外的性能开销，其次，当日志提交失败时，Raft需要回滚相应的配置变更日志，这使得配置变更的实现变得极其复杂。由于“applybefore commit”方式存在这些问题，所以有的Raft配置变更采用的是“apply aftercommit”的方式实现。但是“apply before commit”方式也有一个非常严重的问题——有时会出现死锁现象。

针对相关技术中，采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题，尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种Raft配置变更方法和装置，以至少解决相关技术中采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题。

第一方面，本申请实施例提供了一种Raft配置变更方法，应用于Raft集群中的所有节点，所述方法包括：

节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

在所述集群中的节点个数为两个的情况下，所述节点提交所述日志。

在其中一些实施例中，所述节点在接收到主节点复制过来的日志的情况下，所述方法还包括：

所述节点确定所述日志的内容是否为删除本节点，若否，所述节点确定集群中的节点个数，并在所述集群中的节点个数为两个的情况下，提交所述日志；

若是，所述节点在接收到主节点发送的日志提交确认消息的情况下，提交所述日志。

在其中一些实施例中，所述节点提交所述日志之后，所述方法包括：所述节点应用所述日志之前，禁止其向主节点发送下标消息，其中，所述下标消息用于确认所述节点日志复制到的下标。

在其中一些实施例中，所述确定集群中的节点个数的确定操作的触发时机包括：

若所述节点的倒计时器Election Timeout在计时时段内收不到所述主节点发送的心跳，则所述节点在其倒计时器Election Timeout计时结束后，确定集群中的节点个数。

在其中一些实施例中，所述确定集群中的节点个数之后，所述方法包括：在所述集群中的节点个数为两个的情况下，所述节点提交从主节点复制过来的处于pending状态的日志。

第二方面，本申请实施例提供了一种Raft配置变更装置，应用于Raft集群中的所有节点，所述装置包括：

确定模块，用于在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

提交模块，用于在所述集群中的节点个数为两个的情况下，提交所述日志。

在其中一些实施例中，所述确定模块还用于：

在接收到主节点复制过来的日志的情况下，确定所述日志的内容是否为删除本节点，若否，则确定集群中的节点个数，并在所述集群中的节点个数为两个的情况下，提交所述日志；若是，则在接收到主节点发送的日志提交确认消息的情况下，提交所述日志。

在其中一些实施例中，所述装置还包括：

应用模块，用于在提交所述日志之后，应用所述日志之前，禁止本节点向主节点发送下标消息，其中，所述下标消息用于确认节点日志复制到的下标。

第三方面，本申请实施例还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述Raft配置变更方法。

第四方面，本申请实施例提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述Raft配置变更方法。

相比于相关技术，本申请实施例提供的Raft配置变更方法，通过节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；在集群中的节点个数为两个的情况下，该节点提交日志，解决了相关技术中采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题，提高了系统的运行的安全性和稳定性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请第一实施例的Raft配置变更方法的流程图；

图2是根据本申请第二实施例的Raft配置变更方法的流程图；

图3是根据本申请第三实施例的Raft配置变更方法的流程图；

图4是根据本申请第四实施例的Raft配置变更方法的流程图；

图5是根据本申请第五实施例的Raft配置变更装置的结构框图；

图6是根据本申请实施例的电子设备的内部结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本申请提供的Raft配置变更方法，可以应用于Raft集群中的所有节点。

实施例一

已知在相关技术中，采用“apply after commit”方式的Raft配置变更流程的过程如下：用户向leader（主节点）提交一条配置变更；leader复制这条日志到各个follower（从节点）上，follower回应日志已复制的确认消息至leader；leader根据节点的回应，统计是否半数以上follower上均已复制有该日志，若是则leader提交该日志，并在提交后apply（应用）这条日志和向follow群发日志确认提交的消息；follow收到leader发送的日志确认提交的消息后，也提交该日志，并在follow端也apply（应用）这条日志。

本发明针对造成相关技术中采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题的原因展开分析：

本发明中的Raft 死锁指Raft因为实现上的bug或者算法上的逻辑错误导致集群无法再提交新的数据。考虑一下场景，在一个由leader（主节点）和follower（从节点）组成的两节点的Raft 集群中，用户向leader提交一条配置变更，要求删除leader；leader成功复制这条日志到follower上，commit（提交）并在commit后并apply（应用）这条日志——leader删除了自己，由于leader把自己删了，leader也就没法给follower发送日志提交的确认信息；进而follower上虽然有删除leader的配置变更日志，但是未收到leader发送的日志提交的确认信息，因此follower未能提交这条日志，意味着此时follower上的配置还有两个节点，而此时leader其实已下线，如果当前的主节点宕机或者被网络隔离，集群会通过选举产生新的主节点，即Raft可能会出现主节点切换；但是又由于这是一个由leader（主节点）和follower（从节点）组成的两节点的Raft集群，在leader已下线情形下，集群只剩下单个follower，而仅靠单个follower无法完成选主，因此，这个Raft就陷入死锁状态了——它无法再处理任何读写请求了。

根据以上分析可知，分布式系统在采用“apply after commit”方式变更Raft配置时，若该分布式系统是两节点的集群，则容易发生死锁。进一步的，为了解决两节点集群采用“apply after commit”方式变更Raft配置容易发生死锁的问题，本发明发明人想到Raft是否可以未经主节点确认就提交日志，并且不违背Raft本身的算法，分析过程如下：

已知Raft提交一条日志的充要条件是这条日志已经被复制到过半数的节点上；在相关技术中，Raft算法的实现针对主节点和非主节点设计了两种日志提交方式：针对主节点，由于日志是从主节点复制到其他节点上，所以主节点可以通过非主节点向主节点反馈的日志复制的情况，来推断日志是否已经复制到过半数节点，从而确定日志是否已经提交；针对非主节点，在主节点成功提交一条日志后，主节点会向其他非主节点发送RPC消息，通知日志提交情况，当非主节点收到这条消息且本地存在这条日志，即可提交该日志；以上是一般情况下Raft日志提交的执行过程，无论是主节点还是非主节点，它们都是在了解到日志已经复制到过半数节点的前提下提交日志；

根据Raft日志提交的条件，本发明的发明人发现当集群中只有三个或两个节点的时候，可以让非主节点在未收到主节点的日志提交通知时就直接提交该日志，这样操作并不违背Raft本身的算法，原因是此时主节点和至少一个非主节点上已经有这条日志，已经超过集群的半数节点。

基于此，本实施例提供了一种Raft配置变更方法，应用于Raft集群中的所有节点，图1是根据本申请第一实施例的Raft配置变更方法的流程图，如图1所示，该流程包括如下步骤：

步骤S101，节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

步骤S102，在集群中的节点个数为两个的情况下，该节点提交该日志。

通过步骤S101至S102，相对于相关术中采用“apply after commit”方式实现Raft配置变更的分布式系统有时会死锁的问题，本申请实施例基于“当集群中只有三个或两个节点的时候，可以让非主节点在未收到主节点的日志提交通知的情况下就直接提交日志，这样操作并不违背Raft本身的算法”的研究发现，并分析出发生死锁的场景恰好是发生在两节点的集群中，以及死锁的原因是follower未收到leader发送的日志提交的确认信息，无法删除leader，而此时leader已下线，并且单个follower无法进行重新选主，进而导致死锁，从而在本申请实施例中，通过节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数，在集群中的节点个数为两个的情况下，该节点直接提交该日志，使得在上述两节点集群场景中，follower在未收到leader发送的日志提交的确认信息的情况下，也能删除leader，避免了死锁现象的发生，解决了相关技术中采用“applyafter commit”方式实现Raft配置变更的分布式系统有时会死锁的问题，极大简化了Raft配置变更的实现，提高了系统的运行的安全性和稳定性。

实施例二

进一步的，本发明的发明人发现本申请实施例一的技术方案虽然极大减少了系统死锁现象的发生，但在下述场景下依然会发生死锁：

考虑一下场景，在一个由leader（主节点）、follower （从节点）组成的两节点集群中：用户向主节点提交一条删除follower节点的配置变更日志；主节点将这条日志复制到follower上；follower 收到该日志后，确定集群中节点数量刚好为两个，因此follower 直接把自己删了；如果不巧follower给leader发送RPC确认日志复制消息，在网络传播中丢失了，那么，由于leader未收到follower发送的确认日志复制消息，leader上的配置还是两节点，而此时follower已经下线，导致这个raft集群又死锁了，以上问题主要是非主节点过早删除自己导致的。

基于此，本实施例提供了另一种Raft配置变更方法，应用于Raft集群中的所有节点，图2是根据本申请第二实施例的Raft配置变更方法的流程图，如图2所示，该流程包括如下步骤：

步骤S201，节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定该日志的内容是否为删除本节点；

步骤S202，若否，该节点确定集群中的节点个数，并在集群中的节点个数为两个的情况下，提交该日志；若是，该节点在接收到主节点发送的日志提交确认消息的情况下，提交该日志。

通过步骤S201至步骤S202，针对实施例一中由于非主节点过早删除自己，并遇上了网络传播消息丢失而造成死锁的问题，本申请实施例二通过一个补丁来修复，既禁止非主节点在未接收到主节点发送的日志提交确认消息的情况下删除自己，从而避免了由此带来的死锁问题。

实施例三

进一步的，本发明的发明人发现本申请上述实施例的技术方案虽然极大减少了系统死锁现象的发生，但考虑到从节点平时会、在下线前也可能会发送其消息缓冲区积累的还未对外发送的消息至主节点，因此本申请的上述实施例在下述场景下依然会发生死锁：

考虑一下场景，在一个由leader（主节点）、follower（从节点）组成的两节点集群中：用户向leader提交一条删除follower的配置变更日志；leader commit并apply这条日志把follower删除了；follower提交日志，并向leader发送该follower的消息缓冲区积累的还未对外发送的消息（即下标消息，主要用于让主节点确认该从节点已复制到了哪个日志下标），最后该follower apply日志把自己下线，但由于网络延迟，leader暂时未收到follower发送的该下标消息；此时刚好用户又向leader提交一条添加该follower的配置变更日志，leader commit并apply这条日志把follower加回来；在leader成功添加follower后，网络延迟的该下标消息才抵达leader，leader把follower的matchIndex（非主节点上和主节点匹配度最高的日志下标）调整到该下标消息对应的位置，但follower其实在被删除时已清空日志，再被加上后该follower实际已没有任何日志，下标恢复成了初始值；

此时由于leader上的matchIndex和follower上实际的日志下标对不上，又如果matchIndex无法回退（matchIndex回退操作可能会造成日志重复apply的问题），则就会导致主节点无法复制数据到非主节点上，Raft集群又因此死锁。

基于此，本实施例提供了另一种Raft配置变更方法，应用于Raft集群中的所有节点，图3是根据本申请第三实施例的Raft配置变更方法的流程图，如图3所示，节点提交所述日志之后，该流程包括如下步骤：

步骤S301，该节点应用该日志之前，禁止其向主节点发送下标消息，其中，该下标消息用于确认该节点日志复制到的下标。

通过步骤S301，针对上述实施例中由于从节点在下线前也可能会发送其消息缓冲区积累的还未对外发送的消息至主节点，并恰好遇上了网络延迟，并且该从节点后续又被用户加回来而造成死锁的问题，本申请实施例三通过禁止节点在即将下线时（具体为从该节点提交日志之后至该节点应用日志之前所在的时间段）向主节点发送下标消息，从而避免了由此带来的死锁问题。

实施例四

本发明还对节点确定集群中的节点个数的确认操作的触发时机展开分析，考虑一下场景，在一个三节点的集群中，如果follower2（从节点2）被网络隔离；用户向leader（主节点）提交一条删除follower1（从节点1）的配置变更日志；leader和follower1分别提交并应用这条日志成功删除follower1；用户又向leader提交一条删除leader的配置变更日志，刚好此时follower2结束网络隔离；leader将删除follower1的配置变更日志、删除leader的配置变更日志复制到follower2上，并发送删除follower1的日志确认提交的消息至follower2，然后leader提交并应用删除leader的配置变更日志让自己下线；follower2收到leader的这些日志消息时，它上面的集群还是三节点的配置，因此无法直接提交删除leader的配置变更日志， 此时follower2只能提交并apply删除follower1的配置变更日志，而删除leader的配置变更会一直处于pending（待定）的状态，Raft又陷入死锁状态；

由于此时follower2上follower1已被删除，集群是两节点的配置，而如果当前的主节点宕机或者被网络隔离，集群会通过选举产生新的主节点，即Raft可能会出现主节点切换；因此，可以把节点确定集群中的节点个数的确认操作的触发时机从处理主节点日志复制RPC的时刻调整到发起选举前；非主节点在发起选主前先检查当前集群的配置，如果是两节点状态，则先尝试提交当前处于pending状态的日志；这里需要对pending的日志做尽异步的约束：只有从leader节点上复制过来的日志才能作为pending日志被提交，这样处理是因为存在主节点上的日志可能还未复制到其他节点上，此时主节点变成follower，该follower存在处于pending状态的日志，这部分日志不应被提交的情况。为了对可以提交的pending日志进行标识，可以在Raft算法中添加一个pendingCommit的持久化字段来标识最新的从leader上收到的日志的下标，从而选择提交带有pendingCommit标识的日志；

基于此，本申请提供了另一种Raft配置变更方法，应用于Raft集群中的所有节点，图4是根据本申请第四实施例的Raft配置变更方法的流程图，如图4所示，该流程包括如下步骤：

步骤S401，若所述节点的倒计时器Election Timeout在计时时段内收不到所述主节点发送的心跳，则所述节点在其倒计时器Election Timeout计时结束后，确定集群中的节点个数；

步骤S402，在所述集群中的节点个数为两个的情况下，所述节点提交从主节点复制过来的处于pending状态的Raft配置变更的日志，例如，提交带有pendingCommit标识的Raft配置变更的日志。

通过步骤S401至步骤S402，本实施例四对节点确定集群中的节点个数的确认操作的触发时机展开分析，把节点确定集群中的节点个数的确认操作的触发时机从处理主节点日志复制RPC的时刻调整到发起选举前（节点的倒计时器Election Timeout在计时时段内收不到所述主节点发送的心跳，会触发选主），从而避免因从主节点复制过来的处于pending状态的日志无法提交而造成Raft死锁的情况发生。

实施例五

本申请实施例还提供了一种Raft配置变更装置（Raft Fast Commit装置），该装置应用于Raft集群中的所有节点，图5是根据本申请第五实施例的Raft配置变更装置的结构框图，如图5所示，该装置包括确定模块501和提交模块502，其中：

确定模块501用于在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

提交模块502，用于在集群中的节点个数为两个的情况下，提交日志。

结合上述实施例中的Raft配置变更方法，本申请实施例可提供一种存储介质来实现。该存储介质上存储有计算机程序；该计算机程序被处理器执行时实现上述实施例中的任意一种Raft配置变更方法。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种Raft配置变更方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

在一个实施例中，图6是根据本申请实施例的电子设备的内部结构示意图，如图6所示，提供了一种电子设备，该电子设备可以是服务器，其内部结构图可以如图6所示。该电子设备包括通过内部总线连接的处理器、网络接口、内存储器和非易失性存储器，其中，该非易失性存储器存储有操作系统、计算机程序和数据库。处理器用于提供计算和控制能力，网络接口用于与外部的终端通过网络连接通信，内存储器用于为操作系统和计算机程序的运行提供环境，计算机程序被处理器执行时以实现一种Raft配置变更方法，数据库用于存储数据。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

本领域的技术人员应该明白，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种Raft配置变更方法，其特征在于，应用于Raft集群中的所有节点，所述方法包括：

节点在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

在所述集群中的节点个数为两个的情况下，所述节点提交所述日志。

2.根据权利要求1所述的方法，其特征在于，所述节点在接收到主节点复制过来的日志的情况下，所述方法还包括：

所述节点确定所述日志的内容是否为删除本节点，若否，所述节点确定集群中的节点个数，并在所述集群中的节点个数为两个的情况下，提交所述日志；

若是，所述节点在接收到主节点发送的日志提交确认消息的情况下，提交所述日志。

3.根据权利要求1或2所述的方法，其特征在于，所述节点提交所述日志之后，所述方法包括：所述节点应用所述日志之前，禁止其向主节点发送下标消息，其中，所述下标消息用于确认所述节点日志复制到的下标。

4.根据权利要求1或2所述的方法，其特征在于，所述确定集群中的节点个数的确定操作的触发时机包括：

若所述节点的倒计时器Election Timeout在计时时段内收不到所述主节点发送的心跳，则所述节点在其倒计时器Election Timeout计时结束后，确定集群中的节点个数。

5.根据权利要求4所述的方法，其特征在于，所述确定集群中的节点个数之后，所述方法包括：在所述集群中的节点个数为两个的情况下，所述节点提交从主节点复制过来的处于pending状态的日志。

6.一种Raft配置变更装置，其特征在于，应用于Raft集群中的所有节点，所述装置包括：

确定模块，用于在接收到主节点复制过来的Raft配置变更的日志的情况下，确定集群中的节点个数；

提交模块，用于在所述集群中的节点个数为两个的情况下，提交所述日志。

7.根据权利要求6所述的装置，其特征在于，所述确定模块还用于：

在接收到主节点复制过来的日志的情况下，确定所述日志的内容是否为删除本节点，若否，则确定集群中的节点个数，并在所述集群中的节点个数为两个的情况下，提交所述日志；若是，则在接收到主节点发送的日志提交确认消息的情况下，提交所述日志。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

应用模块，用于在提交所述日志之后，应用所述日志之前，禁止本节点向主节点发送下标消息，其中，所述下标消息用于确认节点日志复制到的下标。

9.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1至5中任一项所述的Raft配置变更方法。

10.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行权利要求1至5中任一项所述的Raft配置变更方法。

Images