一种定时任务调度方法、装置及***
技术领域
本申请涉及计算机应用技术领域,尤其涉及一种定时任务调度方法、装置及***。
背景技术
在集群***中,一种常见的架构是一个调度节点加若干个业务节点,其基本工作模式是:调度节点负责接收集群外部发来的待执行任务,然后根据一定的调度规则将任务分配到多个业务节点上去。
除了集群外部随时可能发来的任务之外,在集群内部还存在一种定时任务,例如在兑换中心(exchange core)***中,要求业务节点每隔一个小时给兑换机构发送HA、TA请求的任务、对兑换机构发送的兑换响应回执、兑换结果报告进行解析的任务等等,这种任务的特点是执行时间可以提前确定。目前,集群***中的定时任务也是由调度节点统一进行调度,具体做法是:对于每一个需要由业务节点执行的定时任务(为便于区别描述,后文将简称为实际任务),都需要在调度节点中配置一个相应的定时任务(为便于区别描述,后文将简称为调度任务),其中,调度任务中记录有对应实际业务的执行时刻、执行节点、执行方式等信息,在调度节点中分配专门的进程实时监控所有的调度任务,以便按时将实际任务分配到相应的业务节点上。
然而,随着集群***规模的扩大以及业务流程的复杂化,集群***中的定时业务数量也越来越多,按照现有的定时任务调度方式,会给调度节点带来很大的压力。而且,由于每增加一个实际任务,就需要在调度节点中配置一个调度任务,这种方式也给***的功能扩展带来了不便。
发明内容
针对上述技术问题,本申请提供一种定时任务调度方法、装置及***,技术方案如下:
根据本申请的第一方面,提供一种定时任务调度方法,应用于业务节点,该方法包括:
接收调度节点发送的定时任务触发消息;
根据所述定时任务触发消息,对业务节点本地的定时任务列表进行扫描,所述任务列表中包含业务节点需要执行的定时任务记录,每条任务记录中至少包含该任务的执行方式信息和执行时刻信息;
根据任务的执行时刻信息,确定当前待执行的任务;
根据任务的执行方式信息,执行所确定的待执行任务。
根据本申请的第二方面,提供一种定时任务调度方法,该方法包括:
调度节点根据本地配置的定时触发任务,向业务节点发送定时任务触发消息,所述定时触发任务中,包含有触发时刻信息及目标业务节点的标识信息;
业务节点接收调度节点发送的定时任务触发消息;根据所述定时任务触发消息,对业务节点本地的定时任务列表进行扫描,所述任务列表中包含业务节点需要执行的定时任务记录,每条任务记录中至少包含该任务的执行方式信息和执行时刻信息;根据任务的执行时刻信息,确定当前待执行的任务;根据任务的执行方式信息,执行所确定的待执行任务。
根据本申请的第三方面,提供一种定时任务调度装置,应用于业务节点,该装置包括:
触发消息接收模块,用于接收调度节点发送的定时任务触发消息;
扫描模块,用于根据所述定时任务触发消息,对业务节点本地的定时任务列表进行扫描,所述任务列表中包含业务节点需要执行的定时任务记录,每条任务记录中至少包含该任务的执行方式信息和执行时刻信息;
任务确定模块,用于根据任务的执行时刻信息,确定当前待执行的任务;
任务执行模块,用于根据任务的执行方式信息,执行所确定的待执行任务。
根据本申请的第四方面,提供一种定时任务调度***,该***包括调度节点侧装置及业务节点侧装置:
调度节点侧装置根据本地配置的定时触发任务,向业务节点发送定时任务触发消息,所述定时触发任务中,包含有触发时刻信息及目标业务节点的标识信息;
业务节点侧装置接收调度节点发送的定时任务触发消息;根据所述定时任务触发消息,对业务节点本地的定时任务列表进行扫描,所述任务列表中包含业务节点需要执行的定时任务记录,每条任务记录中至少包含该任务的执行方式信息和执行时刻信息;根据任务的执行时刻信息,确定当前待执行的任务;根据任务的执行方式信息,执行所确定的待执行任务。
本申请所提供的技术方案,将多个定时任务的详细信息以列表的方式存储在各个业务节点中,而在调度节点中,只需配置少量的触发任务,以便定时告知业务节点,通过扫描本地的任务列表方式自行确认有哪些任务需要执行。与现有的定时任务调度方案相比,调度节点的压力明显减少。另一方面,如果需要给业务节点增加任务,只需要在该节点的任务列表中添加相应的任务记录即可,无需在调度节点侧进行配置修改,有效地提升了***功能扩展的便利性。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是本申请的***架构示意图;
图2是本申请的定时任务调度方法的流程示意图;
图3是本申请的定时任务调度装置的第一种结构示意图;
图4是本申请的定时任务调度装置的第二种结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请保护的范围。
首先对本申请方案的运行***架构进行说明。参见图1所示,本申请方案涉及的交互主体包括:一个调度节点100以及多个业务节点200。其中调度节点100是任务的分配方,业务节点200是任务的执行方。调度节点100与业务节点200之间存在通信连接。各个节点的实际形式可以是物理设备,也可以是虚拟机,本申请对此并不需要进行限定。
在整个***中,存在多个定时任务,这些定时任务需要由各个业务节点来执行。本申请方案与现有技术的区别在于:各个定时任务的详细信息并不存储在调度节点中,而是存储在业务节点中。对于调度节点而言,无需关心每个业务节点、每个任务的执行细节,只需在需要业务节点执行任务时,定时向业务节点发送任务触发消息,然后由业务节点自行检查是否有任务要执行、以及需要执行哪些任务。
图2所示,为本申请提供的定时任务调度方法的流程图,该方法可以包括以下步骤:
S101,调度节点根据本地配置的定时触发任务,向业务节点发送定时任务触发消息。
根据本申请方案,调度节点中依然需要配置定时任务,但是调度节点本身并不需要关注实际任务的细节,只需要记录实际任务需要由哪个/哪些业务节点执行、以及需要在何时触发实际任务执行即可。为方便区别与现有技术进行区别,将本申请方案调度节点中配置的定时任务称为“定时触发任务”。
在一条定时触发任务的记录中,需要包含的基本信息是“触发时刻”以及“目标业务节点的标识”。
其中“触发时刻”可以是一次性有效的时刻,例如“10:00触发”,触发完毕后,该定时触发任务自动失效,或者按照预设的规则对该时刻进行更新,例如在一次触发完毕后,根据触发周期自动对触发时刻进行更新;也可以是具有周期特性的时刻,例如“每天10:00触发”、“每天10:00和22:00”、“每天整点触发”等等。
“目标业务节点的标识”的具体形式可以是目标业务节点的编号、通信地址等等。目标业务节点的数量可以是1个,也可以是多个。对于目标业务节点大于1个的情况,调度节点将在到达触发时刻时,以广播的方式向各个目标业务节点发送定时任务触发消息。
当然,除“触发时刻”以及“目标业务节点的标识”之外,在定时触发任务中还可以进一步包含其他信息,例如上次触发时间、触发次数统计、触发周期等等。本申请对此并不需要进行限定。
假设需要业务节点1执行4个定时任务:在10:00执行任务A和任务B、在11:00执行任务C、在12:00行任务D,根据现有技术的定时任务调度方案,需要在调度节点中配置4个定时任务,并且每个定时任务中需要分别记录任务A/B/C/D的具体细节,包括需要调用的程序、指令、执行参数等。而根据本申请方案,只需要配置1条定时触发任务,设定触发时刻为10:00、11:00、12:00,目标节点为节点1即可。
对于存在多个业务节点的情况,如果存在多个业务节点的业务执行触发时刻要求相同,则可以针对这几个业务节点,配置一个共用的定时触发任务;如果几个节点业务执行时刻不同,则需要针对这几个业务节点分别配置独立的定时触发任务。
可见,如果存在10个业务节点,每个业务节点需要执行20个任务,根据现有技术的定时任务调度方案,需要在调度节点中配置200个定时任务。而利用本申请所提供的定时任务调度方案,至多只需要在调度节点中配置10个定时触发任务,如果存在多个业务节点、其业务执行触发时刻要求相同,那么在调度节点中配置的定时触发任务数量还可以进一步减少,极端情况下(10个业务节点的业务执行触发时刻要求都相同),仅需在调度节点中配置1个定时触发任务即可实现对总共200个定时任务的调度。
S102,业务节点接收调度节点发送的定时任务触发消息后,根据该触发消息对业务节点本地的定时任务列表进行扫描。
根据本申请方案,将定时任务的详细信息保存在需要执行该任务的业务节点中,每个定时任务对应一条任务记录,多条任务记录以列表的形式进行存储,其中,每一条记录中所需要包含的基本信息是该任务的“执行方式”以及“执行时刻”。
其中,“执行方式”,可以是该执行任务需要调用的程序、指令等等,进一步还可以包括任务的执行参数,以实现各种扩展功能,例如输入输出控制、为任务指定优先级、分配处理器、内存资源等等。
“执行时刻”则是该任务的期望执行时刻,与S101中的“触发时刻”类似,该时刻也可以是一次性有效的时刻或者是具有周期特性的时刻。对于一次性有效的时刻,该任务执行完毕后自动失效,或者按照预设的规则进行更新。例如:某任务的执行频率是每小时1次,任务执行之前,记录中的执行时刻是10:00,该时刻表示任务的下次执行时刻。假设任务在10:00时准时执行,则任务执行完毕后,根据该任务的执行频率,自动将下次执行时刻更新为11:00。
需要说明的是,对于同一任务而言,其“触发时刻”与“执行时刻”并不要求严格一致:一方面,从“触发”到“执行”之间必然存在时延,实际应用中,如果对任务执行的时效性要求不高,则不必刻意考虑这个问题,如果对任务执行有一定的时效性要求,则可以,可以将“触发时刻”适当提前一些。
另一方面,由于一个触发任务可能对应多个实际任务,而各个实际任务的要求执行时刻也可能不同,因此“触发时刻”往往比“执行时刻”具有更高的频率。而且,对于时效性较高的任务,也可以采用缩短触发时刻间隔的方式,从而保证任务节点能够及时扫描任务列表并执行任务。
当然,除“执行方式”以及“执行时刻”信息之外,在一条任务记录中还可以进一步包含其他信息,例如上次触发时间、上次执行时间、任务的执行频率(可用于自动更新执行时刻信息)、任务开关标识(用于标识该任务是否有效)等等,本申请对此并不需要进行限定。
表1所示为一种定时任务列表的示例,应当理解的是,该列表仅用于示意性说明,不应该理解为对本申请方案的限定。
表1
S103,根据任务的执行时刻信息,确定当前待执行的任务;
业务节点根据S102的扫描结果,确定当前需要执行的任务。具体而言,对于每一条任务记录,如果当前的时刻满足其执行时刻要求,即可将该任务确定为待执行任务。可以理解的是,这里所说的“满足要求”并不一定是严格意义上的相同,实际往往是“当前时刻晚于执行时刻”即可认为当前需要执行该任务。
另外,如果在任务列表中包含了任务的开关标识信息,则在本步骤中,仅需从任务标识任务记录中,确定当前待执行的任务。以表1为例,假设当前时刻为11:05,则根据“下次执行时刻”,任务1和任务2均满足执行时刻的要求,但是任务2的任务开关为False,表明该任务当前处于无效状态,因此最终仅将任务1确定为待执行任务。
S104,根据任务的执行方式信息,执行所确定的待执行任务。
在本步骤中,根据任务列表中给出的执行方式信息,执行S103所确定的待执行任务。
可见,应用本申请方案,而在调度节点中,只需配置少量的触发任务,使得调度节点的压力明显减少。另一方面,如果需要给业务节点增加任务,只需要在该节点的任务列表中添加相应的任务记录即可,无需在调度节点侧进行配置修改,有效地提升了***功能扩展的便利性。
相应于上述方法实施例,本申请还提供一种应用于业务节点侧的定时任务调度装置,参见图3所示,该装置可以包括:
触发消息接收模块110,用于接收调度节点发送的定时任务触发消息;
扫描模块120,用于根据定时任务触发消息,对业务节点本地的定时任务列表进行扫描,任务列表中包含业务节点需要执行的定时任务记录,每条任务记录中至少包含该任务的执行方式信息和执行时刻信息;
任务确定模块130,用于根据任务的执行时刻信息,确定当前待执行的任务;
任务执行模块140,用于根据任务的执行方式信息,执行所确定的待执行任务。
在本申请的一种具体实施方式中,任务的执行时刻信息具体可以为:该任务的下次执行时刻;任务记录中还包含该任务的执行频率信息;相应地,如图4所示,在定时任务调度装置中还可以包括:执行时刻信息更新模块150,用于在任务执行模块140执行所确定的待执行任务之后,根据任务的执行频率信息,对任务记录中的下次执行时刻进行更新。
在本申请的一种具体实施方式中,任务的执行方式信息中,包含任务的执行参数。
在本申请的一种具体实施方式中,任务记录中,还包含该任务的开关标识;相应地,任务确定模块130可以具体用于:从任务标识为开的任务记录中,确定当前待执行的任务。
本申请还提供一种定时任务调度***,该***包括调度节点侧装置及业务节点侧装置:
其中调度节点侧装置根据本地配置的定时触发任务,向业务节点发送定时任务触发消息,定时触发任务中,包含有触发时刻信息及目标业务节点的标识信息;
业务节点侧装置与前述的应用于业务节点侧的定时任务调度装置相同,这里不再重复说明。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置或***实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置或***实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。