CN116055563A - 基于Raft协议的任务调度方法、系统、电子设备和介质 - Google Patents
基于Raft协议的任务调度方法、系统、电子设备和介质 Download PDFInfo
- Publication number
- CN116055563A CN116055563A CN202211467908.4A CN202211467908A CN116055563A CN 116055563 A CN116055563 A CN 116055563A CN 202211467908 A CN202211467908 A CN 202211467908A CN 116055563 A CN116055563 A CN 116055563A
- Authority
- CN
- China
- Prior art keywords
- node
- task
- executor
- leader node
- executed
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- 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
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1051—Group master selection mechanisms
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
本发明公开了一种基于Raft协议的任务调度方法、系统、电子设备和介质,所述方法包括如下步骤:所述调度服务根据Raft协议从多个节点中选举出leader节点,所述leader节点用于将任务分发给执行器,所述leader节点与数据库双主架构的其中一台服务器保持长连接;每个执行器通过调度服务获取leader节点的信息,并向leader节点发送该执行器的注册信息,所述leader节点根据注册信息在数据库中插入一条执行器信息,然后该执行器与follower节点保持心跳,所述follower节点根据心跳在数据库中更新该执行器对应的心跳时间;所述leader节点获取待执行任务,并根据数据库中的执行器信息将待执行任务分发给相应的执行器;所述执行器接收到待执行任务后,执行待执行任务并向leader节点发送任务接收响应。
Description
技术领域
本发明涉及数据库分布式任务处理,具体涉及一种基于Raft协议的任务调度方法、系统、电子设备和介质。
背景技术
分布式是一种计算机算法,分布式计算是计算机科学中一个研究方向,它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分,然后把这些部分分配给多个计算机进行处理,最后把这些计算结果综合起来得到最终的结果。
任务调度是指系统为了自动完成特定任务,在约定的特定时刻去执行任务的过程。
Raft协议是一个共识算法,即使是在部分节点故障、网络延时、网络分割的情况下,网络中的多个节点也能对某个事情达成一致的看法。
数据库高可用一直都是企业的重中之重,mysql是一种常用的关系型数据库,中小企业很多都会采用mysql主从、一主多从、读写分离等集群部署方案,其中,单主架构存在单点故障,从库切换成主库需要做改动、无法达到自动切换,而采用mysql双主架构(互为主从)虽然可以解决单点故障问题、提高数据库的高可用性,但随之也带来了很多风险,比如数据冲突导致数据覆盖、数据丢失等。
此外,数据的一致性是个老生常谈的问题,在现有的分布式任务调度框架中,为了保证框架的轻量级,部分框架采用了mysql的“for update”数据库锁机制来保证一致性。但由于mysql双主架构下的缺点,采用数据库锁机制来保证一致性的方案也不再能完全满足要求。Mysql双主架构也存在多个方案,比如双主多写与双主单写,其中,双主单写这种方案虽然能达到数据库的高可用,但是在切换时同样无法保证一致性,双主多写也不能完全保证写入的一致性。
发明内容
基于上述现状,本发明的主要目的在于提供一种基于Raft协议的任务调度方法,应用于数据库的双主架构,不采用其他中间件方案,实现了分布式任务调度,能够保证数据的一致性与可用性。
为实现上述目的,本发明采用的技术方案如下:
本发明的第一方面提供了一种基于Raft协议的任务调度方法,应用于数据库的双主架构,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述方法包括如下步骤:
S100,所述调度服务根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
S200,每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
S300,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;
S400,所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应;
S500,所述leader节点接收所述任务接收响应后,重复步骤S300,直至完成所有任务的分发。
优选地,所述步骤S100包括如下步骤:
S110,每个节点初始作为follower节点并随机分配有选举超时时间;
S120,从所述多个节点中选取所述选举超时时间最短的follower节点作为candidate节点;
S130,所述candidate节点向所有的其他节点发起投票请求,
若获得半数以上的投票,则所述candidate节点被选举为leader节点,所述leader节点与至少半数以上的follower节点保持心跳;
若未获得半数以上的投票,则进入步骤S140;
S140,每个所述follower节点进入下一个任期,并作为candidate节点进入步骤S130,直至选举出所述leader节点。
优选地,所述步骤S130中,所述投票请求包含所述candidate节点的当前任期和任务日志ID;
所述每个节点在接收到所述投票请求后,
若所述candidate节点的任务日志ID大于该节点的任务日志ID,则投票给所述candidate节点;
若所述candidate节点的任务日志ID小于该节点的任务日志ID,则不投票给所述candidate节点;
若所述candidate节点的任务日志ID等于该节点的任务日志ID,则比较所述candidate节点的当前任期和该节点的当前任期,
若所述candidate节点的当前任期大于该节点的当前任期,则投票给所述candidate节点;
若所述candidate节点的当前任期小于该节点的当前任期,则不投票给所述candidate节点。
优选地,所述步骤S100包括如下步骤:
S150,若所述follower节点在预设时间内未收到来自所述leader节点的心跳,则执行所述步骤S140。
优选地,所述步骤S200包括如下步骤:
S210,所述每个执行器通过所述调度服务获取所述leader节点的信息的同时,还获取所有的所述follower节点的响应时间,并优先与响应时间最短的follower节点保持心跳。
优选地,所述步骤S200包括如下步骤:
S220,若所述执行器的心跳更新失败,则重新向所述leader节点发送该执行器的注册信息。
优选地,所述步骤S300包括如下步骤:
S310,所述leader节点从所述数据库中获取待执行任务后,检查本地缓存中上一次执行的任务日志,以避免重复分发任务。
优选地,所述步骤S300包括如下步骤:
S320,所述leader节点在分发待执行任务前,随机向半数以上的follower节点发送第一心跳;
若未收到所述follower节点对所述第一心跳的响应,则继续向剩余其他所有的follower节点发送第二心跳,若未收到follower节点对所述第二心跳的响应,则停止分发待执行任务,直至所述通信连接集群中的多个节点恢复心跳;
所述第一心跳和所述第二心跳均包含所述待执行任务的任务日志ID。
优选地,所述步骤S400包括如下步骤:
S410,所述执行器在执行完所述待执行任务后,并优先向所述响应时间最短的follower节点发送任务执行状态。
优选地,所述步骤S400包括如下步骤:
S420,所述执行器接收第一leader节点分发的第一待执行任务后,记录所述第一待执行任务的第一执行时间,并将所述第一leader节点的当前任期作为所述执行器的本地任期;
S430,所述执行器在接收第二leader节点分发的第二待执行任务后,
根据步骤S420记录所述第一执行时间,检测所述第二待执行任务的第二执行时间,以避免重复执行任务;
比较所述本地任期和所述第二leader节点的当前任期,若所述本地任期大于所述第二leader节点的当前任期,则向所述第二leader节点返回过期状态,使得所述第二leader节点变为follower节点。
本发明的第二方面提供了一种基于Raft协议的任务调度系统,应用于数据库的双主架构,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述系统包括:
调度服务组件,用于根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
执行器组件,用于每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
其中,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应。
本发明的第三方面提供了一种电子设备,包括:处理器;以及存储器,所述存储器上存储有计算机程序,所述计算机程序被所述处理器执行时,能够实现如上述第一方面所述的基于Raft协议的任务调度方法。
本发明的第四方面提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序用于运行以实现如上述第一方面所述的基于Raft协议的任务调度方法。
本发明与现有技术相比具有明显的优点和有益效果,其至少具有下列优点:
本发明的基于Raft协议的任务调度方法,应用于数据库的双主架构,通过调度服务从通信连接集群中的多个节点中选举出leader节点,leader节点用于负责任务的分发调度,执行器负责任务的具体执行,由于在通信连接集群中只存在一个leader节点,由leader节点对数据库进行读写操作,由此在数据库层面形成了双主单写,无论是mysql是双主多写还是双主单写,在整个数据库架构中实际上是双主单写的方式,从而保证双主架构下数据的一致性,尤其是任务状态的一致性,以避免在分布式任务调度下任务重复分发和执行。此外,执行器与follower节点保持心跳,一方面可以减少leader节点的负载、有效降低leader节点的服务压力,一方面可以允许执行器短暂下线、及时选取存活状态的执行器。
本发明的基于Raft协议的任务调度系统,通过调度服务组件来确保通信连接集群中只存在一个leader节点,用于分发任务和调度执行器,从而保证mysql双主架构下数据的一致性,同时,执行器与follower节点保持心跳,使得leader节点能够及时获知可调度的执行器,有助于确保任务得到执行,使得任务调度系统可靠性高、一致性强。
本发明的电子设备和计算机可读存储介质,通过采用上述的基于Raft协议的任务调度方法,能够保证mysql双主架构下数据的一致性,使得任务调度系统可靠性高、一致性强。
附图说明
图1为本发明的基于Raft协议的任务调度方法的一种优选实施方式的流程示意图;
图2为本发明的数据库的双主架构的示意图;
图3为本发明的调度服务基于raft协议选举leader节点的示意图;
图4为本发明的leader节点被动失效策略的示意图;
图5为本发明的基于Raft协议的任务调度的一种优选实施方式的结构示意图。
具体实施方式
为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例,对依据本发明提出的方法、系统、电子设备和计算机可读存储介质,其具体实施方式、方法、步骤、特征及其功效,详细说明如后。
参见图1,一种基于Raft协议的任务调度方法,应用于数据库的双主架构,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述方法包括如下步骤:
S100,所述调度服务根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
S200,每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
S300,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;
S400,所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应;
S500,所述leader节点接收所述任务接收响应后,重复步骤S300,直至完成所有任务的分发。
通过上述步骤,通过调度服务从通信连接集群中的多个节点中选举出leader节点,leader节点用于负责任务的分发调度,执行器负责任务的具体执行,通信连接集群中只存在一个leader节点,由leader节点对数据库进行读写操作,由此在数据库层面形成了双主单写,从而保证双主架构下数据的一致性,尤其是任务状态的一致性,以避免在分布式任务调度下任务重复分发和执行。执行器与follower节点保持心跳,一方面可以减少leader节点的负载、有效降低leader节点的服务压力,一方面可以允许执行器短暂下线、及时选取存活状态的执行器。
参见图2,所述数据库的双主架构优选为mysql双主架构,所需执行的任务的元数据和执行器的注册信息均保存在mysql双主架构的数据库中。双主架构的通信连接集群包括多个节点。基于Raft协议,每个节点的角色为leader节点(领导者)、follower节点(追随者)和candidate节点(候选人)的其中之。
具体地,关于步骤S100,调度服务基于Raft协议通过选举阶段从多个节点中选举出leader节点,其余的节点通常作为follower节点,负责任务分派调度的leader节点将所需执行的任务分发给相应的执行器,执行器负责具体的任务代码执行。leader节点在集群中只存在一个,由leader一个节点去读写数据库从而保证mysql双主架构下数据的一致性,follower节点在当leader节点宕机后,通过选举再次选出leader节点,从而保证调度服务的高可用。
具体地,关于步骤S200,当调度服务选出leader节点之后,每个节点都包含leader节点的信息,每个执行器在获取得到leader节点的地址后,向leader节点发送其自身的注册信息。在leader节点根据注册信息在数据库中插入一条执行器信息后,即执行器注册成功后,该执行器向follower节点定时发送心跳,follower节点接收到心跳并在数据库中更新该执行器的“上次心跳时间”字段。一般来说,执行器以ip+端口为唯一key存储在数据库中,leader节点通过调度服务进行执行器的注册操作,对于数据库来说是写操作,由leader节点来统一写入,数据库层面形成了双主单写,无论mysql双主架构是双主多写还是双主单写,在整个架构中始终是双主单写,这样可以保证一致性。执行器向follower发送心跳,一是为了减少leader节点服务的压力,二是因为执行器是可以允许短暂下线的。
具体地,关于步骤S300,在确定完需要执行的任务后,任务日志中待执行任务的任务状态更新为已调度,并由leader节点将待执行任务分发给执行器。
具体地,关于步骤S400,执行器在接收到待执行任务后,会启动一个新线程用于执行相应的待执行任务,并响应于leader节点以表示任务接收成功。
具体地,关于步骤S500,leader节点在接收到执行器发送的任务接收响应后,开始下一轮的任务调度。
作为可选的实施例,参见图3,所述步骤S100包括如下步骤:
S110,每个节点初始作为follower节点并随机分配有选举超时时间;
S120,从所述多个节点中选取所述选举超时时间最短的follower节点作为candidate节点;
S130,所述candidate节点向所有的其他节点发起投票请求,
若获得半数以上的投票,则所述candidate节点被选举为leader节点,所述leader节点与至少半数以上的follower节点保持心跳;
若未获得半数以上的投票,则进入步骤S140;
S140,每个所述follower节点进入下一个任期,并作为candidate节点进入步骤S130,直至选举出所述leader节点。
通过上述步骤,leader节点的选举过程中包含三种角色,candidate节点(候选者)、leader节点(领导者)以及follower节点(跟随者)。每个节点初始状态都为follower节点,随机分配一个选举超时时间。在这个时间内,节点不能成为candidate节点。选举超时时间最短的follower节点会最先成为candidate节点,并向其他的节点发起投票请求,另外两个角色的节点收到请求后,将它们的投票结果返回,获得大多数节点投票(即半数以上节点的投票)的节点就会从candidate节点变为leader节点。
选举成功后,leader节点通过调度服务开始进行任务调度,在设定时间内(例如,每秒)调度即将执行的任务,在任务调度前,可以将此次任务日志(包含任务日志ID)、包含任务的调度时间、任务ID发送给通信连接集群中一半以上的follower节点作为心跳,即使没有任务,调度服务也会使leader节点发送空消息与follower节点保持心跳。其中,任务是指一个业务单元,任务日志是指调度服务操作任务的日志。
作为可选的实施例,所述步骤S130中,所述投票请求包含所述candidate节点的当前任期和任务日志ID;
所述每个节点在接收到所述投票请求后,
若所述candidate节点的任务日志ID大于该节点的任务日志ID,则投票给所述candidate节点;
若所述candidate节点的任务日志ID小于该节点的任务日志ID,则不投票给所述candidate节点;
若所述candidate节点的任务日志ID等于该节点的任务日志ID,则比较所述candidate节点的当前任期和该节点的当前任期,
若所述candidate节点的当前任期大于该节点的当前任期,则投票给所述candidate节点;
若所述candidate节点的当前任期小于该节点的当前任期,则不投票给所述candidate节点。
通过上述步骤,在选举或重新选举leader节点的投票过程中,follower节点可以将当前任期增加1(任期即term作为逻辑时钟,通常为整数,全局递增)则进入下一个任期,将自身变为candidate角色,并请求其他节点投自己一票,请求中包含当前任期与任务日志(包含任务日志ID),其他的节点首先判断对方的任务日志ID是否比自身的大,如果大于自身则投票给对方节点,如果小于则不投票给对方,如果等于则判断对方的当前任期是否大于自身,如果大于则投票给对方。由此,通过比较任务日志ID和当前任期,从而得到最新的任务执行状态,以确保任务状态的一致性,避免任务重复分发和执行。
作为可选的实施例,所述步骤S100包括如下步骤:
S150,若所述follower节点在预设时间内未收到来自所述leader节点的心跳,则执行所述步骤S140。
通过上述步骤,如果在一定的时间内,follower节点没有接收到来自leader的心跳,则发生重新选举,以确定新的leader节点,由此,follower节点在leader节点宕机后,可以通过重新选举及时选出新的leader节点,从而保证任务调度服务的高可用。
作为可选的实施例,所述步骤S200包括如下步骤:
S210,所述每个执行器通过所述调度服务获取所述leader节点的信息的同时,还获取所有的所述follower节点的响应时间,并优先与响应时间最短的follower节点保持心跳。
一般来说,在刚开始与所有的节点进行通信是为了获取leader节点的信息以及测试每个节点的响应时间,然后每个执行器只需要与一个follower节点保持心跳,通过获取节点的响应时间,使得执行器可与响应时间最短的follower节点保持心跳。
通过上述步骤,可以确保及时获取执行器的存活状态,便于leader节点获取可供调度使用的所有的执行器。
作为可选的实施例,所述步骤S200包括如下步骤:
S220,若所述执行器的心跳更新失败,则重新向所述leader节点发送该执行器的注册信息。
通过上述步骤,以确保leader节点在调度任务时可以选取存活的执行器。一般来说,“执行器注册周期时间”+“mysql的binlog同步时间”<=“leader节点判断执行器存活周期时间”。leader节点调度任务时会取存活的执行器。为了减轻leader节点的负载,所以执行器会定时向调度服务follower节点发送心跳。Mysql双主架构的应用也是多样的,如果是mysql双主多写场景,如果执行器写入数据库的节点与leader节点不是同一个节点,那么就存在binlog同步,例如,执行器每30秒更新一下心跳时间,leader节点会查询30秒内保持心跳的执行器,双主多写的场景下,如果binlog同步不及时,就会导致leader节点认为执行器已死,从而影响任务的及时调度。
作为可选的实施例,所述步骤S300包括如下步骤:
S310,所述leader节点从所述数据库中获取待执行任务后,检查本地缓存中上一次执行的任务日志,以避免重复分发任务。
具体地,当调度服务选举出leader节点后,开启定时任务,不断地从数据库中查询出即将需要执行的任务作为待执行任务,查询得到待执行任务后,leader节点会检查本地缓存内上一次执行的任务日志,以避免任务的重复分发。
作为可选的实施例,所述步骤S300包括如下步骤:
S320,所述leader节点在分发待执行任务前,随机向半数以上的follower节点发送第一心跳;
若未收到所述follower节点对所述第一心跳的响应,则继续向剩余其他所有的follower节点发送第二心跳,若未收到follower节点对所述第二心跳的响应,则停止分发待执行任务,直至所述通信连接集群中的多个节点恢复心跳;
所述第一心跳和所述第二心跳均包含所述待执行任务的任务日志ID。
通过上述步骤,leader节点通过探测通信连接集群健康状态,以防止集群中出现脑裂问题,避免导致leader节点重复分发调度任务。
具体地,leader节点在分发任务前会向随机一半以上的follower节点发送心跳,根据这些节点的响应结果来判断相应的节点是否存活,发送心跳时会同步此次待执行任务的任务信息。如果此次探测的节点都没存活,则暂时不分发任务,然后向剩余所有follower节点发送心跳,如果仍然没有节点存货,则认为leader节点已成为孤家寡人,则不再处理任何任务调度,直到与通信连接集群中的其他节点重新获取心跳。由于,发送的心跳包含此次待执行任务的任务日志ID,即使此时发生了重新选举,但是已经执行过的日志存在了大部分节点之上,日志ID最大的节点会优先成为leader节点,这样即使leader节点宕机,新的leader节点再查询出需要执行的任务后,通过检查同步过来的任务日志ID也不会造成任务重复分发。
通过上述步骤,leader节点在调度服务下每次分发任务前都会事先通知follower节点,这样在真正调用前,通信连接集群的多个节点均持有上一次执行的任务信息,当双主架构中的数据库任意一台宕机,或者通信连接集群中的任意一个节点宕机,均能保证任务分派的一致性。
需要说明的是,保证一致性是指系统中并不需要保证执行器的一致性,需要保证的是“任务”状态的一致性,尤其是要保证任务不能重复分发。
作为可选的实施例,所述步骤S400包括如下步骤:
S410,所述执行器在执行完所述待执行任务后,并优先向所述响应时间最短的follower节点发送任务执行状态。
通过上述步骤,在执行器异步执行完任务后,向follower节点更新任务执行状态。尤其是在步骤S210中,每个执行器通过调度服务获取leader节点的信息的同时,还获取所有的follower节点的响应时间,由此,执行器优先向响应时间最短的follower节点更新该次任务的任务执行状态,例如已完成或任务失败。由此,可以及时获取执行器的任务执行状态,以便于leader节点进行后续的任务调度,此外,也可以让用户、开发、运维者及系统管理员查看到调度服务系统的调度情况,用以后续的优化。
作为可选的实施例,所述步骤S400包括如下步骤:
S420,所述执行器接收第一leader节点分发的第一待执行任务后,记录所述第一待执行任务的第一执行时间,并将所述第一leader节点的当前任期作为所述执行器的本地任期;
S430,所述执行器在接收第二leader节点分发的第二待执行任务后,
根据步骤S420记录所述第一执行时间,检测所述第二待执行任务的第二执行时间,以避免重复执行任务;
比较所述本地任期和所述第二leader节点的当前任期,若所述本地任期大于所述第二leader节点的当前任期,则向所述第二leader节点返回过期状态,使得所述第二leader节点变为follower节点。
具体地,关于脑裂问题的处理,通常都会在通信连接集群中部署奇数个节点,投票数过半才能选举出leader节点,以此来避免脑裂问题,但在本发明的实施例中,为了让“旧leader节点”尽快下线,采取了以下两种leader节点失效策略方案。
主动失效策略:参见上述步骤S320,集群状态下,调度服务之间进行长连接,leader节点会每秒查询即将要执行的任务,并放入执行线程池进行处理。等待到预设时间后发送给执行器,在发送前,探测通信连接集群的各个节点的健康状态,如果leader节点无法与大多数节点通信,经过重试一定次数后仍然失败后leader节点下线,这是一种主动失效策略。
被动失效策略:参见图4,假设通信连接集群中包括节点a、b、c,第一次选举后节点a成为了leader节点,当前任期为1,但是节点a由于网络问题无法与节点b和c通信,但是可以访问执行器。节点b、c与节点a失联后发起第二次选举,节点b成为了新的leader节点,当前任期为2。虽然主动失效策略可以解决大部分情,但到了某个极端时刻,比如发生脑裂场景,同时节点迅速重启,导致任务日志丢失,这两个leader节点都会向同一个执行器发起调用。这时候,执行器会比较待执行任务的执行时间,防止任务重复执行,并且根据任期信息向两个leader节点进行不同的响应。当新的leader调用执行器时,执行器更新本地任期,当旧的leader再次调用该执行器时,执行器返回过期状态,例如“old-term”,则旧的leader节点变为“未知”状态,等待网络正常时,则变为follower节点。
参见图5,一种基于Raft协议的任务调度系统,应用于数据库的双主架构,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述系统包括:
调度服务组件,用于根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
执行器组件,用于每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
其中,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应。
由此,通过调度服务组件来确保通信连接集群中只存在一个leader节点,用于分发任务和调度执行器,从而保证mysql双主架构下数据的一致性,同时,执行器与follower节点保持心跳,使得leader节点能够及时获知可调度的执行器,有助于确保任务得到执行。
作为可选的实施例,所述调度服务组件能够使得每个节点初始作为follower节点并随机分配有选举超时时间,并能够从所述多个节点中选取所述选举超时时间最短的follower节点作为candidate节点,能够使得所述candidate节点向所有的其他节点发起投票请求,若获得半数以上的投票,则所述candidate节点被选举为leader节点,所述leader节点与至少半数以上的follower节点保持心跳;若未获得半数以上的投票,则使得每个所述follower节点进入下一个任期,并作为candidate节点向所有的其他节点发起投票请求,直至选举出所述leader节点。
作为可选的实施例,所述执行器组件能够使得所述每个执行器在执行完所述待执行任务后,并优先向所述响应时间最短的follower节点发送任务执行状态。
作为可选的实施例,所述执行器组件能够使得所述每个执行器接收第一leader节点分发的第一待执行任务后,记录所述第一待执行任务的第一执行时间,并将所述第一leader节点的当前任期作为所述执行器的本地任期;并使得所述每个执行器在接收第二leader节点分发的第二待执行任务后,根据所述第一执行时间,检测所述第二待执行任务的第二执行时间,以避免重复执行任务;并能够使得每个执行器比较所述本地任期和所述第二leader节点的当前任期,若所述本地任期大于所述第二leader节点的当前任期,则向所述第二leader节点返回过期状态,使得所述第二leader节点变为follower节点。
本发明还提供了一种电子设备,包括:处理器;以及存储器,所述存储器上存储有计算机程序,所述计算机程序被所述处理器执行时,能够实现如上述实施例所述的基于Raft协议的任务调度方法。
本发明还提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序用于运行以实现如上述实施例所述的基于Raft协议的任务调度方法。
以上所述,仅是本发明的较佳实施例而已,并非对本发明作任何形式上的限制,虽然本发明已以较佳实施例揭露如上,然而并非用以限定本发明,任何熟悉本专业的技术人员,在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容,依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰,均仍属于本发明技术方案的范围内。
Claims (13)
1.一种基于Raft协议的任务调度方法,应用于数据库的双主架构,其特征在于,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述方法包括如下步骤:
S100,所述调度服务根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
S200,每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
S300,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;
S400,所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应;
S500,所述leader节点接收所述任务接收响应后,重复步骤S300,直至完成所有任务的分发。
2.如权利要求1所述的任务调度方法,其特征在于,所述步骤S100包括如下步骤:
S110,每个节点初始作为follower节点并随机分配有选举超时时间;
S120,从所述多个节点中选取所述选举超时时间最短的follower节点作为candidate节点;
S130,所述candidate节点向所有的其他节点发起投票请求,
若获得半数以上的投票,则所述candidate节点被选举为leader节点,所述leader节点与至少半数以上的follower节点保持心跳;
若未获得半数以上的投票,则进入步骤S140;
S140,每个所述follower节点进入下一个任期,并作为candidate节点进入步骤S130,直至选举出所述leader节点。
3.如权利要求2所述的任务调度方法,其特征在于,所述步骤S130中,所述投票请求包含所述candidate节点的当前任期和任务日志ID;
所述每个节点在接收到所述投票请求后,
若所述candidate节点的任务日志ID大于该节点的任务日志ID,则投票给所述candidate节点;
若所述candidate节点的任务日志ID小于该节点的任务日志ID,则不投票给所述candidate节点;
若所述candidate节点的任务日志ID等于该节点的任务日志ID,则比较所述candidate节点的当前任期和该节点的当前任期,
若所述candidate节点的当前任期大于该节点的当前任期,则投票给所述candidate节点;
若所述candidate节点的当前任期小于该节点的当前任期,则不投票给所述candidate节点。
4.如权利要求2所述的任务调度方法,其特征在于,所述步骤S100包括如下步骤:
S150,若所述follower节点在预设时间内未收到来自所述leader节点的心跳,则执行所述步骤S140。
5.如权利要求1所述的任务调度方法,其特征在于,所述步骤S200包括如下步骤:
S210,所述每个执行器通过所述调度服务获取所述leader节点的信息的同时,还获取所有的所述follower节点的响应时间,并优先与响应时间最短的follower节点保持心跳。
6.如权利要求1所述的任务调度方法,其特征在于,所述步骤S200包括如下步骤:
S220,若所述执行器的心跳更新失败,则重新向所述leader节点发送该执行器的注册信息。
7.如权利要求1所述的任务调度方法,其特征在于,所述步骤S300包括如下步骤:
S310,所述leader节点从所述数据库中获取待执行任务后,检查本地缓存中上一次执行的任务日志,以避免重复分发任务。
8.如权利要求1所述的任务调度方法,其特征在于,所述步骤S300包括如下步骤:
S320,所述leader节点在分发待执行任务前,随机向半数以上的follower节点发送第一心跳;
若未收到所述follower节点对所述第一心跳的响应,则继续向剩余其他所有的follower节点发送第二心跳,若未收到follower节点对所述第二心跳的响应,则停止分发待执行任务,直至所述通信连接集群中的多个节点恢复心跳;
所述第一心跳和所述第二心跳均包含所述待执行任务的任务日志ID。
9.如权利要求5所述的任务调度方法,其特征在于,所述步骤S400包括如下步骤:
S410,所述执行器在执行完所述待执行任务后,并优先向所述响应时间最短的follower节点发送任务执行状态。
10.如权利要求1所述的任务调度方法,其特征在于,所述步骤S400包括如下步骤:
S420,所述执行器接收第一leader节点分发的第一待执行任务后,记录所述第一待执行任务的第一执行时间,并将所述第一leader节点的当前任期作为所述执行器的本地任期;
S430,所述执行器在接收第二leader节点分发的第二待执行任务后,
根据步骤S420记录所述第一执行时间,检测所述第二待执行任务的第二执行时间,以避免重复执行任务;
比较所述本地任期和所述第二leader节点的当前任期,若所述本地任期大于所述第二leader节点的当前任期,则向所述第二leader节点返回过期状态,使得所述第二leader节点变为follower节点。
11.一种基于Raft协议的任务调度系统,应用于数据库的双主架构,其特征在于,所述双主架构的通信连接集群包括多个节点,且每个节点能够通过调度服务对所述数据库进行读写操作;
所述系统包括:
调度服务组件,用于根据Raft协议从所述多个节点中选举出leader节点,所述leader节点用于将任务分发给相应的执行器,所述leader节点与所述数据库双主架构的其中一台服务器保持长连接;
执行器组件,用于每个执行器通过所述调度服务获取所述leader节点的信息,并向所述leader节点发送该执行器的注册信息,所述leader节点根据所述注册信息在所述数据库中插入一条执行器信息,然后该执行器与所述多个节点中的follower节点保持心跳,所述follower节点根据所述心跳在所述数据库中更新该执行器对应的心跳时间;
其中,所述leader节点从所述数据库中获取待执行任务,并根据所述数据库中的执行器信息将所述待执行任务分发给相应的执行器;所述执行器接收到所述待执行任务后,执行所述待执行任务并向所述leader节点发送任务接收响应。
12.一种电子设备,其特征在于,包括:
处理器;以及
存储器,所述存储器上存储有计算机程序,所述计算机程序被所述处理器执行时,能够实现如权利要求1至10任一项所述的基于Raft协议的任务调度方法。
13.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序用于运行以实现如权利要求1至10任一项所述的基于Raft协议的任务调度方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211467908.4A CN116055563A (zh) | 2022-11-22 | 2022-11-22 | 基于Raft协议的任务调度方法、系统、电子设备和介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211467908.4A CN116055563A (zh) | 2022-11-22 | 2022-11-22 | 基于Raft协议的任务调度方法、系统、电子设备和介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116055563A true CN116055563A (zh) | 2023-05-02 |
Family
ID=86132002
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211467908.4A Pending CN116055563A (zh) | 2022-11-22 | 2022-11-22 | 基于Raft协议的任务调度方法、系统、电子设备和介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116055563A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117155930A (zh) * | 2023-11-01 | 2023-12-01 | 腾讯科技(深圳)有限公司 | 分布式系统的节点确定方法、任务处理方法及相关装置 |
CN117539642A (zh) * | 2024-01-09 | 2024-02-09 | 上海晨钦信息科技服务有限公司 | 一种信用卡分布式调度平台及调度方法 |
-
2022
- 2022-11-22 CN CN202211467908.4A patent/CN116055563A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117155930A (zh) * | 2023-11-01 | 2023-12-01 | 腾讯科技(深圳)有限公司 | 分布式系统的节点确定方法、任务处理方法及相关装置 |
CN117155930B (zh) * | 2023-11-01 | 2024-02-06 | 腾讯科技(深圳)有限公司 | 分布式系统的节点确定方法、任务处理方法及相关装置 |
CN117539642A (zh) * | 2024-01-09 | 2024-02-09 | 上海晨钦信息科技服务有限公司 | 一种信用卡分布式调度平台及调度方法 |
CN117539642B (zh) * | 2024-01-09 | 2024-04-02 | 上海晨钦信息科技服务有限公司 | 一种信用卡分布式调度平台及调度方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9715522B2 (en) | Information processing apparatus and control method | |
CN116055563A (zh) | 基于Raft协议的任务调度方法、系统、电子设备和介质 | |
US8140623B2 (en) | Non-blocking commit protocol systems and methods | |
US7478114B2 (en) | Failure tolerant transaction processing system | |
US9165025B2 (en) | Transaction recovery in a transaction processing computer system employing multiple transaction managers | |
US6671704B1 (en) | Method and apparatus for handling failures of resource managers in a clustered environment | |
EP2434729A2 (en) | Method for providing access to data items from a distributed storage system | |
US20090113034A1 (en) | Method And System For Clustering | |
US20030149735A1 (en) | Network and method for coordinating high availability system services | |
US7478400B1 (en) | Efficient distributed transaction protocol for a distributed file sharing system | |
CN101079896B (zh) | 一种构建并行存储系统多可用性机制并存架构的方法 | |
US7330860B2 (en) | Fault tolerant mechanism to handle initial load of replicated object in live system | |
US20100017642A1 (en) | Distributed Transaction Processing System Having Resource Managers That Collaborate To Decide Whether To Commit Or Abort A Transaction In Response To Failure Of A Transaction Manager | |
CN101136728A (zh) | 群集系统和用于备份群集系统中的副本的方法 | |
US20080288812A1 (en) | Cluster system and an error recovery method thereof | |
KR20040015223A (ko) | 클러스터형 컴퓨터 시스템의 자원 작용 수행 방법,클러스터형 컴퓨터 시스템 및 그의 수행을 위한 컴퓨터프로그램 | |
US20120011100A1 (en) | Snapshot acquisition processing technique | |
KR101296778B1 (ko) | NoSQL 데이터베이스를 위한 결과적 트랜잭션 처리 방법 | |
CN106844014A (zh) | 分布式事务防悬挂的实现方法和装置 | |
CN105511987A (zh) | 一种强一致性且高可用的分布式任务管理系统 | |
CN112039970A (zh) | 一种分布式业务锁服务方法、服务端、系统及存储介质 | |
CN115098229A (zh) | 事务处理方法、装置、节点设备及存储介质 | |
US6873987B1 (en) | Method, system and program products for recovering from failures within a shared nothing distributed computing environment | |
CN108600284B (zh) | 一种基于Ceph的虚拟机高可用实现方法及系统 | |
US20060235853A1 (en) | Use of retry period in an application server to ensure that status information is sent from first to second database instance |
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 |