一种优化Raft集群的方法、装置及存储介质

技术领域

本发明涉及分布式数据库技术领域，尤其涉及一种优化Raft集群的方法、装置及存储介质。

背景技术

在目前的数据库搭建方案中，数据中心内部通常会搭建一组Border Leaf交换机，连接到外部路由设备，实现数据中心网络和外网的连接。这组Border Leaf交换机功能一致，可采用多虚一的形态，对外表现为一台性能强大的逻辑交换机，用于承载数据中心内部和数据中心外部间的通信流量。由于每台Border Leaf交换机存储的配置信息需要保持一致，所以在每台Border Leaf交换机内驻留OVSDB存储配置信息，通过统一管理形成一个分布式集群数据库，达到多台交换机中的配置存储信息一致的目的；

Raft是工程上使用较为广泛的去中心化、高可用的分布式协议。OVSDB分布式集群数据库，基于分布式共识的Raft算法实现集群的高可用。但是根据Raft算法，为便于选举结果的产生，集群需要三个或更多参与节点，参与节点数量通常需要奇数个，并且当半数以上节点故障后，集群就会停止工作。

但是在实际使用中，常常出现Border Leaf交换机数量不满足奇数个的情况，造成使用Raft算法时选举效率低，经常不能一次性选举出集群Leader节点。而且由于Raft算法的约束，当半数以上节点故障后，集群就会停止工作，会导致当集群中还有接近半数的交换机数据库节点正常，却不能继续完成用户配置的存储。这些问题亟需优化解决。

发明内容

本发明的实施例提供一种优化Raft集群的方法、装置及存储介质，提高了borderleaf组交换机的运行稳定性，并且保持了集群中节点数量为奇数，以便于Raft算法的稳定运行。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明的实施例提供的方法，包括：

S1、启动集群中的节点，其中，完成启动操作后的集群中节点的类型包括：工作节点和辅助节点，工作节点和辅助节点的数量总和为奇数；

S2、在发起选举后，工作节点和辅助节点运行投票规则，并从工作节点中确定作为Leader的节点；

S3、作为Leader的节点向集群中的其它节点发送心跳报文，接收到所述心跳报文的工作节点和辅助节点跟随所述作为Leader的节点。

第二方面，本发明的实施例提供的装置，包括：

初始化模块，用于启动集群中的节点，其中，完成启动操作后的集群中节点的类型包括：工作节点和辅助节点，工作节点和辅助节点的数量总和为奇数；

选举模块，用于在发起选举后，工作节点和辅助节点运行投票规则，并从工作节点中确定作为Leader的节点；

管理模块，用于作为Leader的节点向集群中的其它节点发送心跳报文，接收到所述心跳报文的工作节点和辅助节点跟随所述作为Leader的节点。

第三方面，本发明的实施例提供的存储介质，存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现第一方面中本发明的实施例提供的方法。

本发明实施例提供的优化Raft集群的方法、装置及存储介质，通过增加辅助节点，扩大了数据库节点基数。当实际在用的数据库节点只要还存在一台Leader节点，整个OVSDB数据库集群还可以正常运行，从而提高了border leaf组交换机的运行稳定性。并且当border leaf组交换机为偶数时，可以通过增加辅助节点，使得集群中节点数量为奇数，以便于Raft算法的运行，从而提高选举效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例提供的工作节点的运行流程示意图；

图2为本发明实施例提供的辅助节点运行流程的示意图；

图3为本发明实施例提供的一种具体实例的示意图；

图4、图5为本发明实施例提供的另一种具体实例的示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本实施例的设计思路，主要在于：提出辅助节点的概念并应用在Raft集群中，具体做法是扩充一定数量的辅助节点参与到Raft集群选举中，并进一步通过对Raft算法的改进和优化，达到集群仅剩最后一个工作节点Leader时也可以正常服务的效果。通过辅助节点，集群中节点总数量还可以方便从偶数扩展为奇数，提升选举效率。

本发明实施例提供一种优化Raft集群的方法，包括：

S1、启动集群中的节点，其中，完成启动操作后的集群中节点的类型包括：工作节点和辅助节点，工作节点和辅助节点的数量总和为奇数。

S2、在发起选举后，工作节点和辅助节点运行投票规则，并从工作节点中确定作为Leader的节点。

S3、作为Leader的节点向集群中的其它节点发送心跳报文，接收到所述心跳报文的工作节点和辅助节点跟随所述作为Leader的节点。

具体的，在步骤S2中可以包括：

工作节点启动时为Follower状态，若已经存在Leader，跟随所述Leader，并保持Follow状态。倘若在预设时间段内没有收到来自Leader的心跳报文，则从Follower状态切换到Candidate状态，并发起选举。辅助节点启动后保持在Follower状态，若在预设时间段内没有收到来自Leader的心跳报文，则保持静默并等待其它节点发起选举。

在步骤S3中可以包括：处于Candidate状态的工作节点若收到半数以上的投票，则切换到Leader状态，如果选举过程中发现其他节点比自己更新，则主动切换到Follower，跟随已有Leader。辅助节点在接收到投票请求后运行投票规则，确定投票或拒绝，之后再次检测是否收到Leader的心跳报文，若是，则跟随发出心跳报文的Leader。

例如：在集群节点启动后，其中工作节点的运行流程如图1所示的，包括：启动时是Follower状态，如果已经存在Leader，跟随已有Leader，保持Follow状态。如果在一段时间内没有收到来自Leader的心跳，从Follower切换到Candidate，发起选举。Candidate如果收到半数以上的票则切换到Leader状态，其中，Candidate收到的票包含Candidate自己的一票如果选举过程中发现其他节点比自己更新，则主动切换到Follower，跟随已有Leader。这个流程和Raft规定的状态迁移方式一致。集群节点启动后，其中辅助节点的运行流程如图2所示的，包括：启动后始终保持在Follower状态，如果在一段时间内如果没有收到来自Leader的心跳，则保持静默，等待其他节点发起选举后立即投票。如果收到投票请求，则按照投票规则，确定投票或拒绝。如果收到Leader的心跳，则跟随该Leader。

进一步的，本实施例中所述的集群的启动操作包括：检测到所述集群中的工作节点数为N，其中N为正整数。建立N-1个辅助节点,并添加进所述集群中。假如当完成启动操作后，所述集群中的辅助节点发生故障时，销毁发生故障的辅助节点，并重建与销毁数量相同的辅助节点，将重建的辅助节点添加进所述集群中。例如：如图3所示的，当集群工作节点数为N时，额外增加N-1个辅助节点,扩充后集群节点总数量变为2N-1。达到效果：当原集群N-1个工作节点故障，仅剩最后一个工作节点Leader时，集群仍然可以正常工作。因为此时集群还有工作节点中的1个Leader和N-1个辅助节点，共计N个节点工作超过半数的节点工常工作，集群会继续运行下去。如果个别辅助节点发生故障，立即销毁并重建相同数量的辅助节点进行补充，使得辅助节点数量始终保持在N-1个。

本实施例中，可以将参与集群的节点分为两类：1)工作节点：运行在交换机内部的数据存储节点，工作状态机和Raft算法定义的一致，可以在Raft定义的领导者(Leader)、跟从者(Follower)和候选人(Candidate)三种状态间切换。2)辅助节点：运行在服务器内部，这是用于提升工作节点可靠性的节点，其运行状态和Raft定义的运行状态机不同，永远工作在Follower状态，永远不会成为集群中的Leader，也永远不会主动发起选举。即辅助节点可以设置于外部服务器上，一方面，通过设备外存储副本进一步增强了集群的可靠性；另一方面，节约了borderleaf交换机上宝贵的设备内存。

具体的，支撑数据中心设备工作的Borderleaf交换机中的OVSDB节点，或其他类型运用raft算法实现的分布式集群存储节点，被配置为集群中的工作节点，而在服务器上建立OVSDB节点加入集群，，作为所述集群的辅助节点；或其他类型运用raft算法实现的分布式集群存储节点加入集群，作为所述集群的辅助节点。

进一步的，本实施例中还针对集群运行中的日志一致性问题进行了设计，其中：在完成启动操作后的所述集群中，正常运行的工作节点数量≥2。当Leader接收到由客户端发送的请求时，Leader将会把该请求作为新的内容添加到日志中。然后将该日志通过消息发送到网络中其他Follower，从而复制该日志。Follower接收到该日志消息后则会返回复制成功的回复。在Leader接收到网络中大部分的Follower的成功复制的确认，且确认的节点包含除Leader外的一个工作节点，Leader便认为该日志可以被提交在更新日志的过程中，日志确认的节点包含除Leader外的一个工作节点。可以理解为，本实施例的集群内数据一致性约束的要求在原有Raft基础上进行扩展。具体的，Raft数据一致性约束包含：1)一个日志被复制到大多数节点，就会确认日志提交，保证不会回滚。2)Leader一定包含最新的确认日志，因此Leader只会追加日志，不会删除覆盖日志。3)不同节点，某个位置上日志相同，那么这个位置之前的所有日志一定是相同的。在增加辅助节点后，由于只有工作节点会主动发起选举，而辅助节点即使具备最新的日志副本，也不会在Leader故障时主动发起选举成为新Leader，因此需要扩展以下约束规则：当集群中工作节点正常运行数量大于等于2时，此时日志确认的大多数节点中必须包含除Leader外的一个工作节点，Raft才能保证被复制到大多数节点的日志不会被回滚。因为Leader故障时，拥有最新日志的其他工作节点可以通过选举成为新Leader。若从投票者视角看，给出选票需要同时满足两个条件：1)先到先得。2)发选举请求的Candidate所拥有的日志不能比自己低。第7点结合第6点保证了拥有最新日志的工作节点才有资格当选新Leader。从而在原有raft一致性保证的要求上，增加了一条约束——当集群中工作节点正常运行数量大于等于2时，此时日志确认的大多数节点中必须包含除Leader外的一个工作节点，Raft才能保证被复制到大多数节点的日志不会被回滚。

下面结合实际应用中的具体应用场景，举例说明本实施例的实现方式：

在架构设计方面，整个分布式数据库集群中存在A-K共计11个节点，其中BorderLeaf上的工作节点为A-F共6个节点，服务器上辅助节点为G-K共5个节点。满足工作节点为N，辅助节点为N-1的数量要求。

在节点的运行方面，Raft算法将时间分为一个个的任期(term)，每一个term的开始都是Leader选举。在成功选举Leader之后，Leader会在整个term内管理整个集群。目前正处于term 3,A节点通过竞选成为Leader，其他节点均处于Follow状态。Leader选出后，就开始接收客户端的配置请求。Leader对配置请求分配Log index，通过Log index对日志进行编号和标记，然后并行的向其他节点复制日志条目。当这条日志被复制到大多数服务器上，Leader将这条日志应用到它的状态机并向客户端返回执行结果，集群内部确认Logindex对应的这条日志被提交，不会再回滚。当前集群中已经完成Logindex＝5的日志提交，因为日志5已经被A,B,G,H,I,J,K的大于半数的节点所确认，并且当集群中工作节点正常运行数量大于等于2时，此时日志确认的大多数节点中必须包含除Leader外的一个工作节点，这里是节点B确认了Logindex＝5的日志提交，满足了这一约束。

若在某一时刻，如图4所示的，节点A故障，所有的Follow超过一段时间没有收到来自Leader的心跳，工作节点B、C、D、E和F从Follower切换到Candidate，发起选举。而辅助节点G、H、I、J和K知道主故障，会继续保持静默，不会主动发起选举。B、C、D、E和F根据Leader的心跳的超时，先后转入Candidate状态，开始发起投票，G、H、I、J和K收到C、D、E和F的投票请求时，发现投票请求中携带的Logindex比自己的小，说明日志没有自己的新，不会给出选票。当收到B的投票请求时，发现投票请求中携带的Logindex和自己一样大，满足投票要求，把自己的选票投给B；B获得了半数以上的票数(B、G、H、I、J和K)，成功当选新Leader,,继续接收客户端的配置请求。由于重新进行了一次选举，当前进入Term 4任期，在这个任期内，如果如图5那样的，出现了最差情况，C、D、E和F工作节点也相继故障，无法工作，这时仍然有B、G、H、I、J和K节点正常，超过集群半数节点正常工作，因此集群继续运行。

用户提交的新的配置请求，分配log index＝7，由于B、G、H和K都进行对日志进行了确认，因此向用户返回配置成功的结果。此时集群中工作节点正常运行数量小于2，此时日志确认的大多数节点中不再要求包含除Leader外的一个工作节点。

从上述实施例在应用场景中的实现可以看出，当数据库集群原工作节点为偶数时，可以在外部服务器上增加辅助节点，使得扩充后节点数量为奇数，提升选举效率。扩充适当数量的辅助节点，当集群内工作节点故障，仅剩最后一个工作节点Leader时，集群仍然可以正常工作。

本实施例中，将分布式集群数据库中的节点角色分为工作节点和辅助节点两类。其中，辅助节点的主要作用是扩大集群节点基数，支持集群工作，只参加选举，不主动发起选举。集群中工作节点和辅助节点的数量规定：当集群工作节点数为N时，额外增加N-1个辅助节点,扩充后集群节点总数量变为2N-1。并且辅助节点设置在服务器上，故障时能够快速重启，保证集群中中正常运行节点超过半数。

本实施例中还对日志一致性策略进行了扩展：在原有raft一致性保证的要求上，增加了一条约束——当集群中工作节点正常运行数量大于等于2时，此时日志确认的大多数节点中必须包含除Leader外的一个工作节点，Raft才能保证被复制到大多数节点的日志不会被回滚。当数据库集群原工作节点为偶数时，可以在外部服务器上增加辅助节点，使得扩充后节点数量为奇数，提升选举效率。

本实施例的方案扩充适当数量的辅助节点，当集群内工作节点故障，极端情况下仅剩最后一个工作节点Leader时，集群仍然可以正常工作。

本发明实施例中，还提供一种优化Raft集群的装置，所述装置具体可以通过计算机程序编写并封装为各个虚拟模块，并运行在用于管理服务器的管理节点上。从硬件层面上看，管理节点具体可以实现为集群中的服务器设备，或者所述服务器设备中建立的虚拟机，再或者采用其它常见手段在服务器集群中建立的、能够被本领域技术人员所通常理解的节点。所述优化Raft集群的装置，包括：

初始化模块，用于启动集群中的节点，其中，完成启动操作后的集群中节点的类型包括：工作节点和辅助节点，工作节点和辅助节点的数量总和为奇数。

选举模块，用于在发起选举后，工作节点和辅助节点运行投票规则，并从工作节点中确定作为Leader的节点。

管理模块，用于作为Leader的节点向集群中的其它节点发送心跳报文，接收到所述心跳报文的工作节点和辅助节点跟随所述作为Leader的节点。

所述选举模块，具体用于工作节点启动时为Follower状态，若在预设时间段内没有收到来自Leader的心跳报文，则从Follower状态切换到Candidate状态，并发起选举；辅助节点启动后保持在Follower状态，若在预设时间段内没有收到来自Leader的心跳报文，则保持静默并等待其它节点发起选举；

所述管理模块，具体用于处于Candidate状态的工作节点若收到半数以上的投票，则切换到Leader状态；辅助节点在接收到投票请求后运行投票规则，之后再次检测是否收到Leader的心跳报文，若是，则跟随发出心跳报文的Leader；

Borderleaf交换机中的OVSDB节点配置为所述集群中的工作节点；在服务器上建立辅助节点，当工作节点数为N时，建立N-1个辅助节点,并添加进所述集群中，其中，N为正整数。

本发明实施例中，还提供一种存储介质，其中存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现本发明实施例中所提及的方法流程，例如上述S1-S3的方法流程以及其中的具体流程细节。

本实施例在实际应用中，通过在Raft算法中创新加入辅助节点对Raft算法进行优化，满足数据中心Border Leaf交换机组的使用要求。辅助节点的加入扩大了集群节点基数，当集群原工作节点总数为N时，额外增加N-1个辅助节点,扩充后集群节点总数量变为2N-1。达到如下的改进目的：1)当数据库集群原工作节点为偶数时，可以在外部服务器上增加辅助节点，使得扩充后节点数量为奇数，提升选举效率；2)当原集群N-1个工作节点故障，仅剩最后一个工作节点Leader时，集群仍然可以正常工作。因为此时集群还有1个Leader工作节点和N-1个辅助节点，共计N个节点正常工作，仍有超过半数的节点工作。如果个别辅助节点发生故障，立即销毁重建，使得辅助节点数量稳定保持为N-1个。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。