CN111526186A - 基于Raft的分布式服务器集群配置方法 - Google Patents
基于Raft的分布式服务器集群配置方法 Download PDFInfo
- Publication number
- CN111526186A CN111526186A CN202010278020.0A CN202010278020A CN111526186A CN 111526186 A CN111526186 A CN 111526186A CN 202010278020 A CN202010278020 A CN 202010278020A CN 111526186 A CN111526186 A CN 111526186A
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- request
- leader
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5007—Internet protocol [IP] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于Raft的分布式服务器集群配置方法,通过配置集群节点,对各个集群节点进行分区,修改整个服务器集群的状态,使网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态,此外跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点,按照相应规则使该候选人节点成为该网络分区的新任领导者节点,并更新任期号,以实现对相应分布式服务器集群的配置。
Description
技术领域
本发明涉及分布式信号处理技术领域,尤其涉及一种基于Raft的分布式服务器集群配置方法。
背景技术
在现代社会,很多时候处理一些事务需要使用很多台计算机,那么如何保证这些机器在一起运作的时候像一个整体而不相互分离隔绝就是分布式系统的一致性算法需要解决的问题。一致性并不意味着结果的正确性,而是分布式系统中的多个物理节点在经过处理后所展示的状态是否一致。现在人们普遍使用的分布式一致性算法是Paxos算法,Paxos算法从1990年提出到现在已经有三十年的时间了,期间有很多的研究者和团队试图改进Paxos算法,但是Paxos算法本身晦涩难懂,在实际系统的应用上也难以推进,必须要对其结构进行大幅度修改才能应用。所以我们迫切需要找到一种简便且易于理解的一致性算法来提升工作效率以及为以后的一致性算法的教学和推广打下基础,而本发明基于的Raft算法是在该种情况下由Stanford提出,意在取代Paxos算法,在Raft算法一经推出后立即得到一致性算法领域学者的重视,通过对Raft算法的不断研究和改进,越来越多的研究者和团队将一致性算法研究和应用的重点转移到了Raft算法上来。
随着互联网技术的不断发展,各大互联网企业的业务量也呈现出爆发式的增长。故而,分布式架构就显得越发重要。目前,国内外的很多公司和研究机构都对分布式环境下的一致性处理方法进行了研究,现根据已有方案中应用的主要技术概括目前研究和水平如下:
Basic-Paxos算法
基于Paxos协议构建的系统,只需要系统中超过半数的节点在线且相互通信正常即可正常对外提供服务。它的核心实现Paxos Instance主要包括两个阶段:准备阶段(prepare phase)和提议阶段(accept phase)。Basic-Paxos算法的基本流程如下:
获取一个ProposalId,为了保证ProposalId递增,可以采用时间戳+serverId方式生成;
提议者向所有节点广播prepare(n)请求;
接收者比较n和minProposal,如果n>minProposal,表示有更新的提议,minProposal=n;否则将(acceptedProposal,acceptedValue)返回;
提议者接收到过半数请求后,如果发现有acceptedValue返回,表示有更新的提议,保存acceptedValue到本地,然后跳转1,生成一个更高的提议;
到这里表示在当前paxos instance内,没有优先级更高的提议,可以进入第二阶段,广播accept(n,value)到所有节点;
接收者比较n和minProposal,如果n>=minProposal,则acceptedProposal=minProposal=n,acceptedValue=value,本地持久化后,返回;否则,返回minProposal。
提议者接收到过半数请求后,如果发现有返回值>n,表示有更新的提议,跳转1;否则value达成一致。
两阶段必不可少,Prepare阶段的作用是阻塞旧的提议,并且返回已经接收到的acceptedProposal。
Multi-Paxos算法
Paxos算法是对一个值达成一致,Multi-Paxos是连续多个Paxos Instance来对多个值达成一致,这里最核心的原因是Multi-Paxos协议中有一个Leader。Leader是系统中唯一的Proposal,在Lease租约周期内所有提案都有相同的ProposalId,可以跳过Prepare阶段,议案只有Accept过程,一个ProposalId可以对应多个Value,所以称为Multi-Paxos。
选举:首先我们需要有一个Leader,其实选举的实质也是一次Paxos算法的过程,只不过这次确定的“谁是Leader”这个值。由于任何一个节点都可以发起提议,在并发情况下,可能会出现多主的情况,比如A,B先后当选为Leader。为了避免频繁选举,当选Leader的节点要马上树立自己的Leader权威(让其它节点知道它是Leader),写一条特殊日志(Start-Working日志)确认其身份。根据多数派原则,只有一个Leader的StartWorking日志可以达成多数派。Leader确认身份后,可以通过了Lease机制(租约)维持自己的Leader身份,使得其它Proposal不再发起提案,这样就进入了Leader任期,由于没有并发冲突,因此可以跳过Prepare阶段,直接进入Accept阶段。通过分析可知,选出Leader后,Leader任期内的所有日志都只需要一个网络RTT(Round Trip Time)即可达成一致。
新主恢复流程:由于Paxos中并没有限制,任何节点都可以参与选举并最终成为Leader,这就无法保证新选出的Leader包含了所有日志,可能存在空洞,因此在真正提供服务前,还存在一个获取所有已提交日志的恢复过程。领导者节点向所有成员查询最大logId的请求,收到多数节点响应后,选择最大的logId作为日志恢复结束点,这里多数节点的意义在于恢复结束点包含了所有达成一致的日志,当然也可能包含了没有达成多数节点的日志。获得logId后,从头开始对每个logId逐条进行Paxos协议,因为在新主获得所有日志之前,系统是无法提供服务的。为了优化,引入了Confirm机制,就是将已经达成一致的logId告诉其它Acceptor,Acceptor写一条Confirm日志到日志文件中。那么Leader在重启后,扫描本地日志,对于已经拥有Confirm日志的Log,就不会重新发起Paxos流程。同样的,在响应客户端请求时,对于没有Confirm日志的Log,需要重新发起一轮Paxos流程。由于没有严格要求Confirm日志的位置,可以批量发送。为了确保重启时,不需要对太多已提价的Log进行Paxos流程,需要将Confirm日志与最新提交的logId保持一定的距离。
性能优化:Basic-Paxos过程的一次日志确认,需要至少两次磁盘写操作(Prepare,Promise)和两次网络RTT(Prepare,Promise)。Multi-Paxos利用一阶段提交(省去Prepare阶段),将一次日志确认缩短为一个RTT和一次磁盘写操作;通过Confirm机制,可以缩短新Leader的恢复时间。为了提高性能,我们还可以实现一批日志作为一个组提交,要么成功一批,要么都不成功,这点类似于Group-Commit,通过RT换取吞吐量。
在过去的十几年里,Paxos算法一直是分布式一致性领域里面的标杆,但是由于其复杂性、难以理解,故而难以在实际的商业系统中实现,这就容易使分布式服务器集群的相关配置过程变得复杂,影响配置效率。
发明内容
针对以上问题,本发明提出一种基于Raft的分布式服务器集群配置方法。
为实现本发明的目的,提供一种基于Raft的分布式服务器集群配置方法,包括如下步骤:
S1,配置集群节点,读取管理员输入的各个集群节点IP地址;
S2,在初始化状态,服务器集群中的节点都是处于跟随者状态时,对各个集群节点进行分区,得到多个网络分区;
S3,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态;
S4,系统返回一个请求流量入口的IP地址;
S5,客户端向服务器集群发送请求;
S6,若整个服务器集群处于初始化状态,则返回执行步骤S2,若服务器集群不全处于初始化状态,则执行步骤S7;
S7,在一个网络分区的集群节点中,如果客户端的请求发送到跟随者节点,则拒绝接收此请求,并重定向,返回执行步骤S5;如果客户端的请求发送到领导者节点,则接收此请求;
S8,每个网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点;
S9,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应;
S10,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态;
S11,跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点;
S12,候选人节点先投自己一票,并向所在网络分区的其余节点发送投票请求;
S13,收到投票请求的跟随者节点如果在该任期里没有将选票投出,则将选票投给该候选人节点;
S14,如果候选人节点获得的选票数超过设定票数,则该候选人节点成为该网络分区的新任领导者节点,并更新任期号。
在一个实施例中,对各个集群节点进行分区包括:
以网络作为分区的依据对所有节点进行分区。
在一个实施例中,修改整个服务器集群的状态包括:
在内存中定义一个整形变量,以记录服务器集群的状态;所述整形变量的初始值为0,0表示初始化状态;修改后的服务器集群的状态为1,1表示运行状态。
在一个实施例中,重定向包括:
向客户端返回一个响应信息,使客户端再次客户端向服务器集群发送请求。
在一个实施例中,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态包括:
采用随机函数在各个网络分区所有节点ID的范围内进行选取,选出的ID对应的节点为相应网络分区的领导者节点;待所有网络分区都有领导者节点后,把整个服务器集群的状态从初始状态修改为运行状态;其中初始化状态下,集群中的所有节点都是跟随者。
上述基于Raft的分布式服务器集群配置方法,通过配置集群节点,对各个集群节点进行分区,得到多个网络分区,修改整个服务器集群的状态,使每个网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态,此外跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点,按照相应规则使该候选人节点成为该网络分区的新任领导者节点,并更新任期号,以实现对相应分布式服务器集群的配置。其中采用了强领导者的方式来简化数据一致性处理方法,赋予了领导者节点更多的功能和责任,在心跳检测信息的基础上增加了随机选举超时时间,以此来进行领导者节点选举,在可理解性上大大增强,易于实现,且相应系统操作简洁,只需进行相应节点的配置,无需其余复杂操作。
附图说明
图1是一个实施例的基于Raft的分布式数据一致性处理系统的模块组成图;
图2是一个实施例的基于Raft的分布式服务器集群配置方法流程图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
参考图1所示,图1为一个实施例的基于Raft的分布式服务器集群配置方法流程图,包括如下步骤:
S1,配置集群节点,读取管理员输入的各个集群节点IP地址。
S2,在初始化状态,服务器集群中的节点都是处于跟随者状态时,对各个集群节点进行分区,得到多个网络分区。
具体地,对各个集群节点进行分区包括:
以网络作为分区的依据对所有节点进行分区。
进一步地,确定网络分区的具体过程及其作用为:根据不同的网络地址给集群中的节点进行划分,把合适数量的服务器节点划分到同一个网络区域中;网络分区的作用在于能更好地管理服务器节点,也能把客户端发送的请求通过负载均衡的方法更好地分配给合适的节点进行处理。
S3,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态。
具体地,修改整个服务器集群的状态包括:
在内存中定义一个整形变量,以记录服务器集群的状态;所述整形变量的初始值为0,0表示初始化状态;修改后的服务器集群的状态为1,1表示运行状态;即整形变量的初始值为0;修改整个服务器集群的状态就是把该整型变量从0改为1。
进一步地,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态包括:
采用随机函数在各个网络分区所有节点ID的范围内进行选取,选出的ID对应的节点为相应网络分区的领导者节点;待所有网络分区都有领导者节点后,把整个服务器集群的状态从初始状态修改为运行状态;其中初始化状态下,集群中的所有节点都是跟随者。即,初始化状态下,集群中的所有节点都是跟随者,在每个网络分区中随机选出一个领导人节点,采用随机函数在该分区所有节点ID的范围内进行选取,选出的ID对应的节点为该分区的领导人(领导者节点);待所有分区都有领导人后,把整个服务器集群的状态从初始状态修改为运行状态。
S4,系统返回一个请求流量入口的IP地址。
上述系统可以指数据一致性处理系统。在一个示例中,这个系统用于处理服务器集群的数据一致性的,故而与服务器有关。此时系统与服务器的关系是“管理”与“被管理”的关系。
S5,客户端向服务器集群发送请求。
S6,若整个服务器集群处于初始化状态,则返回执行步骤S2,若服务器集群不全处于初始化状态,则执行步骤S7。
S7,在一个网络分区的集群节点中,如果客户端的请求发送到跟随者节点,则拒绝接收此请求,并重定向,返回执行步骤S5;如果客户端的请求发送到领导者节点,则接收此请求。
具体地,重定向包括:
向客户端返回一个响应信息,使客户端再次客户端向服务器集群发送请求。
具体地,判别接收请求的节点的状态的具体流程可以包括:请求到达服务器集群后,若收到此请求的节点是跟随者,则拒绝处理此请求,并让客户端重定向,客户端需再次发送该请求到集群;若收到请求的节点是领导人,则把该请求复制给该分区的其余跟随者节点去执行操作;此过程是强领导者机制的重要体现,所有客户端发送的请求都需要经过领导人节点。
S8,每个网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点。
S9,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应。
S10,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态。
上述设定数量可以依据相应网络分区中的跟随者节点数设置,比如设为超过相应网络分区中的跟随者节点数一半的值等等。
上述步骤明确了请求需要经过集群中的大多数节点操作后才能真正提交到集群中。
S11,跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点。
S12,候选人节点先投自己一票,并向所在网络分区的其余节点发送投票请求。
S13,收到投票请求的跟随者节点如果在该任期里没有将选票投出,则将选票投给该候选人节点。
S14,如果候选人节点获得的选票数超过设定票数,则该候选人节点成为该网络分区的新任领导者节点,并更新任期号。
上述设定票数可以依据相应网络分区中的跟随者节点数设置,比如设为超过相应网络分区中的跟随者节点数一半的值等等。
本实施例在Raft算法的基础上提出了一种强领导者、更加容易理解、更易于实现的分布式一致性处理方法及系统。该方法通过选举出一个领导者节点,给予领导者更多的功能和责任,从而降低算法的复杂性,并更易于实现;该系统用于配置集群节点、分发请求流量以及处理节点的数据一致性。
上述基于Raft的分布式服务器集群配置方法,通过配置集群节点,对各个集群节点进行分区,得到多个网络分区,修改整个服务器集群的状态,使每个网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态,此外跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点,按照相应规则使该候选人节点成为该网络分区的新任领导者节点,并更新任期号,以实现对相应分布式服务器集群的配置。其中采用了强领导者的方式来简化数据一致性处理方法,赋予了领导者节点更多的功能和责任,在心跳检测信息的基础上增加了随机选举超时时间,以此来进行领导者节点选举,在可理解性上大大增强,易于实现,且相应系统操作简洁,只需进行相应节点的配置,无需其余复杂操作。
在一个实施例中,运行上述基于Raft的分布式服务器集群配置方法的分布式数据一致性处理系统采用了多模块的结构,具体可以包括:
集群节点配置模块:系统管理员在该模块中对集群节点的IP地址进行配置,以便系统对集群节点的数据一致性进行处理;
请求流量入口模块:客户端对于整个集群的请求都需要经过该入口模块,该模块用于请求流量的分发;
集群节点数据一致性处理模块:该模块是整个数据一致性处理系统的核心,该模块基于Raft算法处理集群节点的数据一致性。
在一个实施例中,上述基于Raft的分布式服务器集群配置方法也可以通过如下过程表述:
S1、如附图1所示,本分布式数据一致性处理系统中包含集群节点配置模块,管理员需在该模块中输入集群中所有节点的IP地址进行配置并提交至系统中的集群节点数据一致性处理模块;
S2、如附图2所示,初始化状态下,服务器集群中的节点都应处于跟随者状态,所以给整个服务器集群进行初始化操作;一般在实际的商业系统环境中,服务器集群中的节点数量是很多的,所以应该以网络为依据对整个集群中的节点进行分区,分区的目的是为了更方便、更灵活地管理节点,也为了更好地对外提供服务,因为分区以后对于客户端的请求可以更方便地进行负载均衡。
S3、在每个网络分区的服务器集群中随机选出一个领导人节点,可以把该分区的所有节点的ID作为范围,采用随机函数从该范围中选出一个数字,选出的数字对应的ID的节点作为领导人。待所有分区的服务器集群都有领导人节点后,把整个集群的状态从“初始状态”修改为“运行状态”。
S4、如附图1所示,在系统对集群节点配置完毕后,分布式数据一致性处理系统返回一个请求流量入口的IP地址至请求流量入口模块,该模块用于接收客户端发送的所有请求,并将这些请求进行分流至集群节点。
S5、客户端向服务器集群发送请求。在集群接收请求之前需要对客户端的请求进行负载均衡,通过综合判断每个分区的节点的负载情况(包括节点处理任务数、内存利用率、磁盘占有率等)来选择合适的分区里面的节点接收该请求。
S6、判断整个服务器集群的状态,如果集群处于“初始状态”,则拒绝接收该请求,并回到S1;如果集群处于“运行状态”,则进行S7;
S7、判断接收到请求的节点的状态,如果该节点是跟随者,则拒绝接收此请求,并响应客户端,让客户端重定向,再次发送该请求;如果该节点是领导人,那么就处理请求。
在本方法中,相比于跟随者节点,领导人节点有更多的功能和责任,客户端发送给服务器集群的所有请求都必须经过领导人接收处理,跟随者无权接收客户端的请求,只能让客户端重定向;这是一种强领导者机制,可以在降低可理解性的基础上保证集群的数据一致性。
S8、接收了客户端的请求后,每个分区里的领导人节点需要把该请求发送给该分区里面的所有跟随者节点,这是维护集群数据一致性的开始步骤。
S9、跟随者接收到领导人发送的请求后,需要执行请求里面对于数据库的操作,对于数据库进行操作以后,跟随者会接收到执行结果,根据执行结果来响应该分区的领导人节点;如果执行成功,则返回执行成功的标志给领导人节点,否则返回执行失败的标志给领导人节点。
S10、当领导人节点收到该分区里面的大多数(超过一半)跟随者节点执行成功的信息时,则发送该请求的执行成功的标志给一台专门管理请求提交状态的专有节点,如果该专有节点收到大多数(超过一半)分区的领导人节点发送的该请求执行成功的信息,那么该专有节点会响应所有分区的领导人节点,通知各领导人节点该请求可以提交,故而,该请求处于提交状态;否则,该请求就不能真正提交,在该请求不能真正提交的状态下,需要各跟随者节点回滚该请求中对于数据库的操作。
S11、跟随者节点如果在选举超时时间结束之前没有收到该分区里面的领导人的心跳检测信息,那么该跟随者就成为候选人,使任期号在当前基础上加一,并发起选举。
在某个节点成为领导人后,为了维护其领导人的地位,也为了让跟随者节点知道其存活状态,需要领导人节点每隔固定的时间(心跳检测时间)给其分区的跟随者节点发送心跳检测信息,跟随者节点在收到心跳检测信息后就将其选举超时时间归零,使其重新开始计时。
为了选举的成功率,在设置节点的选举超时时间时,是采用一个区域范围内的随机数进行设置,一般这个范围是在150毫秒到300毫秒之间;这样做以后,每个节点的选举超时时间在很大概率上是不同的,所以在如果在选举超时时间结束时没有收到领导人的心跳检测信息,那么一般是选举超时时间最短的跟随者节点成为候选人,而且很大概率上是只有一个节点成为候选人,这样就避免了多个候选人进行选举,而其获得的票数一样继而无法选举出领导人的现象出现。
S12、候选人节点先投自己一票,然后给其所属的分区里的其余跟随者节点发送投票请求。
S13、收到投票请求的跟随者节点如果在当前任期中没有将自己的票投出,那么就把选票投给请求的候选人,对于单个跟随者节点而言,在有多个(大于一个)候选人的情况下,投票采用先来先得的原则;如果跟随者节点已经在当前任期中投出了选票,则不能再次投票。
S14、如果候选人获得了其所属的分区里的大多数跟随者节点的投票,则其成为该分区里的新任领导者,并真正地更新任期号;如果出现S9所述的多个候选人票数相等而无法选出领导人的情况,那么此次选举作废,需要重新选举,直到选举出领导人为止。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
需要说明的是,本申请实施例所涉及的术语“第一\第二\第三”仅仅是区别类似的对象,不代表针对对象的特定排序,可以理解地,“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序。应该理解“第一\第二\第三”区分的对象在适当情况下可以互换,以使这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
本申请实施例的术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、装置、产品或设备没有限定于已列出的步骤或模块,而是可选地还包括没有列出的步骤或模块,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或模块。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。
Claims (5)
1.一种基于Raft的分布式服务器集群配置方法,其特征在于,包括如下步骤:
S1,配置集群节点,读取管理员输入的各个集群节点IP地址;
S2,在初始化状态,服务器集群中的节点都是处于跟随者状态时,对各个集群节点进行分区,得到多个网络分区;
S3,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态;
S4,系统返回一个请求流量入口的IP地址;
S5,客户端向服务器集群发送请求;
S6,若整个服务器集群处于初始化状态,则返回执行步骤S2,若服务器集群不全处于初始化状态,则执行步骤S7;
S7,在一个网络分区的集群节点中,如果客户端的请求发送到跟随者节点,则拒绝接收此请求,并重定向,返回执行步骤S5;如果客户端的请求发送到领导者节点,则接收此请求;
S8,每个网络分区的领导者节点将客户端的请求发送给该网络分区的其余跟随者节点;
S9,当跟随者节点将客户端的请求所包括的操作执行在本地数据库里面以后,向相应网络分区的领导者节点发送响应;
S10,当领导者节点收到相应网络分区跟随者节点的响应超过设定数量后,将客户端的请求设为提交状态;
S11,跟随者节点如果在选举超时时间之内没有接收到领导者节点发送的心跳检测信息,那么该跟随者节点成为候选人节点;
S12,候选人节点先投自己一票,并向所在网络分区的其余节点发送投票请求;
S13,收到投票请求的跟随者节点如果在该任期里没有将选票投出,则将选票投给该候选人节点;
S14,如果候选人节点获得的选票数超过设定票数,则该候选人节点成为该网络分区的新任领导者节点,并更新任期号。
2.根据权利要求1所述的基于Raft的分布式服务器集群配置方法,其特征在于,对各个集群节点进行分区包括:
以网络作为分区的依据对所有节点进行分区。
3.根据权利要求1所述的基于Raft的分布式服务器集群配置方法,其特征在于,修改整个服务器集群的状态包括:
在内存中定义一个整形变量,以记录服务器集群的状态;所述整形变量的初始值为0,0表示初始化状态;修改后的服务器集群的状态为1,1表示运行状态。
4.根据权利要求1所述的基于Raft的分布式服务器集群配置方法,其特征在于,重定向包括:
向客户端返回一个响应信息,使客户端再次客户端向服务器集群发送请求。
5.根据权利要求1所述的基于Raft的分布式服务器集群配置方法,其特征在于,在每个网络分区中随机选出一个领导者节点,等到所有网络分区的小集群都有了领导者节点以后,修改整个服务器集群的状态包括:
采用随机函数在各个网络分区所有节点ID的范围内进行选取,选出的ID对应的节点为相应网络分区的领导者节点;待所有网络分区都有领导者节点后,把整个服务器集群的状态从初始状态修改为运行状态;其中初始化状态下,集群中的所有节点都是跟随者。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010278020.0A CN111526186A (zh) | 2020-04-10 | 2020-04-10 | 基于Raft的分布式服务器集群配置方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010278020.0A CN111526186A (zh) | 2020-04-10 | 2020-04-10 | 基于Raft的分布式服务器集群配置方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111526186A true CN111526186A (zh) | 2020-08-11 |
Family
ID=71902792
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010278020.0A Pending CN111526186A (zh) | 2020-04-10 | 2020-04-10 | 基于Raft的分布式服务器集群配置方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111526186A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112181305A (zh) * | 2020-09-30 | 2021-01-05 | 北京人大金仓信息技术股份有限公司 | 数据库集群网络分区选择方法和装置 |
CN112822078A (zh) * | 2021-02-26 | 2021-05-18 | 浪潮云信息技术股份公司 | 一种不同网域中各节点raft心跳上报的实现方法 |
CN113254278A (zh) * | 2021-07-10 | 2021-08-13 | 北京开科唯识技术股份有限公司 | 一种用于处理互联网请求的方法和系统 |
CN113282041A (zh) * | 2021-05-26 | 2021-08-20 | 广东电网有限责任公司 | 一种集群测控装置的参数校核方法、系统、设备及介质 |
CN113342483A (zh) * | 2021-03-16 | 2021-09-03 | 江苏大学 | 一种基于Raft的分布式任务调度系统 |
CN113742254A (zh) * | 2021-01-19 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 内存碎片治理方法、装置和系统 |
CN114629806A (zh) * | 2022-04-13 | 2022-06-14 | 腾讯科技(成都)有限公司 | 数据处理方法、装置、电子设备、存储介质及程序产品 |
CN115048061A (zh) * | 2022-07-22 | 2022-09-13 | 北京邮电大学 | 基于Raft的冷数据存储方法 |
CN115277719A (zh) * | 2022-05-20 | 2022-11-01 | 西安工业大学 | 一种基于优先级的共识方法和分布式系统 |
CN115840631A (zh) * | 2023-01-04 | 2023-03-24 | 中科金瑞(北京)大数据科技有限公司 | 基于raft的高可用分布式任务调度方法和设备 |
CN116028250A (zh) * | 2021-10-26 | 2023-04-28 | 慧与发展有限责任合伙企业 | 具有多个集群级别的分解式存储 |
CN116723192A (zh) * | 2023-08-10 | 2023-09-08 | 苏州海加网络科技股份有限公司 | 一种基于联邦学习的分布式共识系统及其运行方法 |
CN116743786A (zh) * | 2022-02-25 | 2023-09-12 | 比亚迪股份有限公司 | 基于Raft算法的轨道交通系统控制方法、系统和存储介质 |
CN117220884A (zh) * | 2023-09-05 | 2023-12-12 | 上海雷龙信息科技有限公司 | 一种数字签名交互验证方法、系统、设备和介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105512266A (zh) * | 2015-12-03 | 2016-04-20 | 曙光信息产业(北京)有限公司 | 一种实现分布式数据库操作一致性的方法及装置 |
CN106559263A (zh) * | 2016-11-17 | 2017-04-05 | 杭州沃趣科技股份有限公司 | 一种改进的分布式一致性算法 |
US20170116095A1 (en) * | 2015-10-27 | 2017-04-27 | Netapp, Inc. | Third vote consensus in a cluster using shared storage devices |
CN107528710A (zh) * | 2016-06-22 | 2017-12-29 | 华为技术有限公司 | raft分布式系统领导节点的切换方法、设备及系统 |
-
2020
- 2020-04-10 CN CN202010278020.0A patent/CN111526186A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170116095A1 (en) * | 2015-10-27 | 2017-04-27 | Netapp, Inc. | Third vote consensus in a cluster using shared storage devices |
CN105512266A (zh) * | 2015-12-03 | 2016-04-20 | 曙光信息产业(北京)有限公司 | 一种实现分布式数据库操作一致性的方法及装置 |
CN107528710A (zh) * | 2016-06-22 | 2017-12-29 | 华为技术有限公司 | raft分布式系统领导节点的切换方法、设备及系统 |
CN106559263A (zh) * | 2016-11-17 | 2017-04-05 | 杭州沃趣科技股份有限公司 | 一种改进的分布式一致性算法 |
Non-Patent Citations (1)
Title |
---|
李迪: "基于Raft协议及RocksDB的分布式统一配置中心设计与实现", 《中国优秀硕士学位论文全文数据库(电子期刊)信息科技辑》 * |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112181305A (zh) * | 2020-09-30 | 2021-01-05 | 北京人大金仓信息技术股份有限公司 | 数据库集群网络分区选择方法和装置 |
CN112181305B (zh) * | 2020-09-30 | 2024-06-07 | 北京人大金仓信息技术股份有限公司 | 数据库集群网络分区选择方法和装置 |
CN113742254A (zh) * | 2021-01-19 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 内存碎片治理方法、装置和系统 |
CN112822078A (zh) * | 2021-02-26 | 2021-05-18 | 浪潮云信息技术股份公司 | 一种不同网域中各节点raft心跳上报的实现方法 |
CN113342483A (zh) * | 2021-03-16 | 2021-09-03 | 江苏大学 | 一种基于Raft的分布式任务调度系统 |
CN113342483B (zh) * | 2021-03-16 | 2024-05-10 | 江苏大学 | 一种基于Raft的分布式任务调度系统 |
CN113282041A (zh) * | 2021-05-26 | 2021-08-20 | 广东电网有限责任公司 | 一种集群测控装置的参数校核方法、系统、设备及介质 |
CN113254278A (zh) * | 2021-07-10 | 2021-08-13 | 北京开科唯识技术股份有限公司 | 一种用于处理互联网请求的方法和系统 |
CN116028250A (zh) * | 2021-10-26 | 2023-04-28 | 慧与发展有限责任合伙企业 | 具有多个集群级别的分解式存储 |
CN116028250B (zh) * | 2021-10-26 | 2024-06-11 | 慧与发展有限责任合伙企业 | 具有多个集群级别的分解式存储 |
CN116743786A (zh) * | 2022-02-25 | 2023-09-12 | 比亚迪股份有限公司 | 基于Raft算法的轨道交通系统控制方法、系统和存储介质 |
CN114629806B (zh) * | 2022-04-13 | 2023-12-12 | 腾讯科技(成都)有限公司 | 数据处理方法、装置、电子设备、存储介质及程序产品 |
CN114629806A (zh) * | 2022-04-13 | 2022-06-14 | 腾讯科技(成都)有限公司 | 数据处理方法、装置、电子设备、存储介质及程序产品 |
CN115277719A (zh) * | 2022-05-20 | 2022-11-01 | 西安工业大学 | 一种基于优先级的共识方法和分布式系统 |
CN115277719B (zh) * | 2022-05-20 | 2024-05-31 | 西安工业大学 | 一种基于优先级的共识方法和分布式系统 |
CN115048061A (zh) * | 2022-07-22 | 2022-09-13 | 北京邮电大学 | 基于Raft的冷数据存储方法 |
CN115840631A (zh) * | 2023-01-04 | 2023-03-24 | 中科金瑞(北京)大数据科技有限公司 | 基于raft的高可用分布式任务调度方法和设备 |
CN115840631B (zh) * | 2023-01-04 | 2023-05-16 | 中科金瑞(北京)大数据科技有限公司 | 基于raft的高可用分布式任务调度方法和设备 |
CN116723192A (zh) * | 2023-08-10 | 2023-09-08 | 苏州海加网络科技股份有限公司 | 一种基于联邦学习的分布式共识系统及其运行方法 |
CN116723192B (zh) * | 2023-08-10 | 2023-11-28 | 苏州海加网络科技股份有限公司 | 一种基于联邦学习的分布式共识系统及其运行方法 |
CN117220884A (zh) * | 2023-09-05 | 2023-12-12 | 上海雷龙信息科技有限公司 | 一种数字签名交互验证方法、系统、设备和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111526186A (zh) | 基于Raft的分布式服务器集群配置方法 | |
US6532494B1 (en) | Closed-loop node membership monitor for network clusters | |
US7185096B2 (en) | System and method for cluster-sensitive sticky load balancing | |
JP7270755B2 (ja) | 分散システムでのメタデータルーティング | |
CN102025550A (zh) | 一种分布式集群中数据管理的系统和方法 | |
CN101771723A (zh) | 数据同步方法 | |
CN104011701A (zh) | 内容传送网络 | |
CN114756519A (zh) | 与无状态同步节点的托管文件同步 | |
US20230367749A1 (en) | Data migration method and apparatus, device, medium, and computer product | |
CN1338687A (zh) | 用于集群计算机系统的合并协议 | |
CN113064764B (zh) | 在区块链系统中执行区块的方法及装置 | |
CN110347718A (zh) | 一种redis分片方法、装置、计算机设备和存储介质 | |
CN112650812A (zh) | 一种数据分片存储方法、装置、计算机设备和存储介质 | |
CN110830582B (zh) | 一种基于服务器集群选主方法和装置 | |
CN113157450A (zh) | 在区块链系统中执行区块的方法及装置 | |
US11121874B2 (en) | Method for analyzing data using a blockchain, a data provider and a data customer therefor | |
US20190372825A1 (en) | Communication apparatus, communication method, and recording medium | |
CN101789963A (zh) | 数据同步系统 | |
CN111770178A (zh) | 一种领导节点选举方法及系统 | |
WO2023048942A1 (en) | Enabling an action based on a permission identifier for real-time identity resolution in a distributed system | |
CN110290215B (zh) | 一种信号传输方法及装置 | |
US20170118082A1 (en) | Systems and methods for an intelligent, distributed, autonomous, and scalable resource discovery, management, and stitching | |
CN113612732A (zh) | 一种资源调用方法、装置和多方安全计算系统 | |
CN116760837B (zh) | 一种基于联邦学习和权益选举的分布式共识方法及系统 | |
CN113157494B (zh) | 区块链系统中数据备份的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200811 |
|
RJ01 | Rejection of invention patent application after publication |