CN115934287B - 应用系统多服务集群下定时任务调度方法 - Google Patents

Abstract

本申请公开一种应用系统多服务集群下定时任务调度方法，涉及集群服务器领域，接收指令创建任务，将任务对应数据存入数据库并同步到redis缓存中；查询redis缓存的任务列表，根据任务列表中各任务的状态信息更新可执行任务列表；基于redis分布式机制获取可执行任务列表对应的任务锁争抢列表，通过争抢锁机制和任务的前序条件完成情况确定目标任务；对目标任务创建子任务线程，并放到本地线程池中异步执行和同步redis缓存。本方案采用redis争抢锁机制来抢占任务，对关联性任务采用前序条件和后续条件核验机制来校验，确保高并发状态下任务不会重复触发，且采用线程池分配的方案避免了数据库io高占用和锁死的问题。

Description

应用系统多服务集群下定时任务调度方法

技术领域

本申请实施例涉及服务器领域，特别涉及一种应用系统多服务集群下定时任务调度方法。

背景技术

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。一旦在服务器上安装并运行了集群服务，该服务器即可加入群集。集群化操作可以减少单点故障数量，并且实现了群集化资源的高可用性。

当应用系统处于多服务集群部署状态下时，由于存在服务同一个定时任务会被重复触发，如果存在关联任务时相关联的任务也会被同时触发，这就可能会造成一个任务执行多遍。

针对重复触发和执行的情况，现有分布式任务调度主要有以下两种解决方案：

1.OpenSymphony开源组织的Quartz定时任务组件。该组件使用数据库锁的方式解决多服务情况下相同任务被同时唤醒的问题，但是无法实现连锁任务的级联触发。需要额外配置定时任务对前一任务查询或者自己在任务中手动触发下一任务。由于使用数据库锁在服务集群较大或任务较多的情况下会造成数据库io阻塞严重影响数据库性能。并且Quartz组件是java开发只能在java生态中使用。

2.xxljob任务调度系统。该系统是由个人开发者在Quartz开源组件的基础上进行二次开发，实现了关联任务自动触发功能。同样由于其基于Quartz核心逻辑还是数据库锁，同样会造成数据库io阻塞。并且由于其为java开发并且是个独立运行的平台，如果需要集成进现在系统会有一定的门槛。

发明内容

本申请提供一种应用系统多服务集群下定时任务调度方法，解决多服务集群部署状态下定时任务和关联任务重复触发的问题，所述方法包括：

接收指令创建任务，将任务对应数据存入数据库并同步到redis缓存中；

任务核心线程启动并完成数据同步后，查询所述redis缓存的任务列表，根据所述任务列表中各任务的状态信息更新所述可执行任务列表；其中，所述任务列表中包含有所有创建且未执行完毕的任务和对应状态信息，所述可执行任务列表中包含有所述任务核心线程确定的具备执行条件的任务；

基于redis分布式机制获取所述可执行任务列表对应的任务锁争抢列表，通过争抢锁机制和任务的前序条件完成情况确定目标任务；

对所述目标任务创建子任务线程，并放到本地线程池中异步执行和同步所述redis缓存。

具体的，所述redis缓存还包含有所述任务列表对应的争抢锁列表；所述争抢锁列表包括所有服务对任务的争抢状态；

所述状态信息至少包括每个任务的争抢锁id、任务id、任务参数、定时信息、执行类名、任务重试次数及最大重试次数、任务当前状态、前序任务列表和后续任务列表；所述前序任务列表和所述后续任务列表中包含有执行该任务需要的前序任务和后续任务；所述定时信息为触发该任务争抢机制的时间。

具体的，所述查询所述redis缓存的查询任务列表，根据所述任务列表中各任务的状态信息更新所述可执行任务列表，包括：

轮询所述任务列表，根据所述定时信息确定新触发任务，根据任务当前状态、争抢锁id及争抢状态、任务重试次数及最大重试次数确定可执行任务；

基于所述可执行任务和所述新触发任务更新所述可执行任务列表；

其中，可执行任务为历史执行失败的任务，且执行次数小于最大重试次数。

具体的，集群服务器包含若干服务，所述可执行任务列表中的任务对应争抢锁为未占用状态，任务当前状态为未执行状态；

更新所述可执行任务列表后，所述方法还包括：

基于任务类型和任务参数对所述可执行任务列表中的所有任务进行归类，将存在关联条件的任务建立各自的所述前序任务列表及所述后续任务列表。

具体的，所述基于redis分布式机制获取所述可执行任务列表对应的任务锁争抢列表，通过争抢锁机制和任务的前序条件完成情况确定目标任务，包括：

核对所述可执行任务列表中各个候选任务对应前序任务的完成状态，并将前序任务未完成的所述候选任务滤除，获得中间任务列表；

基于redis分布式机制对所有中间任务执行多任务争抢，将争抢到的所述中间任务作为所述目标任务，同步更新所述目标任务的任务重试次数、执行信息时间、以及最晚完成时间。

具体的，当所述目标任务在最晚完成时间内未完成执行任务时，争抢锁自动失效；所述执行信息时间为目标服务争抢到锁的时间，且抢到锁后的争抢锁更新为已占用状态。

具体的，所述对所述目标任务创建子任务线程，并放到本地线程池中异步执行和同步所述redis缓存，包括：

对所述目标任务创建所述子任务线程，并在本地线程池中执行；

根据任务参数执行内容，并记录日志信息；

执行完成后根据结果更新所述redis缓存中的所述任务列表，用于任务核销。

具体的，当所述目标任务包含有所述后续任务列表时，读取并更新所述redis缓存中的所述任务列表和所述可执行任务列表，继续通过争抢锁执行后续任务。

具体的，任务核心线程移交任务到本地线程池中执行后进入休眠状态；然后获取当前所述中间任务列表；当所述中间任务列表不存在满足执行条件的任务时结束线程，否则继续根据所述中间任务列表执行争抢任务。

本申请提供的技术方案带来的有益效果至少包括：通过在集群服务器中引入redis缓存机制，实时根据数据库内容更新redis缓存内容，并按照所建任务的争抢锁状态和条件完成情况来选择目标任务，特别是在多任务触发条件下，可以确保每个任务都具有时间上的连贯性，且不会被重复占用和执行。而关联性任务之间则按照前序条件来进行筛选，避免关联任务被重复占用执行，确保任务顺利执行。采用任务核心线程和任务子线程分离执行的机制，可以大幅提高批量任务下的并发率，大幅减少数据库io占用。同时还是负载每一个任务到不同服务内，通过配置线程池能够调整每个服务最大任务数灵活配置使任务分配更优充分使用服务器资源。使用该方案后完美消除了数据库io瓶颈。

附图说明

图1是本申请实施例提供的应用系统多服务集群下定时任务调度方法的流程图；

图2是本申请另一实施例提供的应用系统多服务集群下定时任务调度方法的流程图；

图3是本申请实施例提供的应用系统多服务集群下定时任务调度方法的算法流程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

图1是本申请实施例提供的应用系统多服务集群下定时任务调度方法的流程图，包括如下步骤：

步骤101，接收指令创建任务，将任务对应数据存入数据库并同步到redis缓存中。

当应用系统应用在多服务集群下，就存在多个服务(例如服务器包括服务A、服务B、服务C等)，这些服务可能会触发同一个定时任务，造成重复执行的情况。为此，本方案设置了redis缓存，当服务器集群在接收指令创建任务时，将任务对应的数据同步到redis缓存和数据库中。需要说明的是，redis缓存是更新的，因而只需要缓存需要执行的数据即可，数据库内容这才是全量数据。

步骤102，任务核心线程启动并完成数据同步后，查询redis缓存的任务列表，根据任务列表中各任务的状态信息更新可执行任务列表。

任务核心线程基于任务触发，或者是在达到预设的触发条件后触发，触发后首先将redis缓存和数据库缓存进行同步，匹配同步的目的是在数据库内容变更时，及时将redis缓存更新，避免执行出错。

redis缓存的任务列表中含有创建任务后，且未执行完毕的任务，同时包含有任务对应状态信息。而可执行任务列表中包含有任务核心线程确定的具备执行条件的任务，用于在后续过程中执行选定目标任务并执行。状态信息描述了各个任务的执行状态以及基本信息，在触发执行后，根据该对应状态信息判断是否满足执行条件，并将移入到可执行任务列表中作为备选项。

步骤103，基于redis分布式机制获取可执行任务列表对应的任务锁争抢列表，通过争抢锁机制和任务的前序条件完成情况确定目标任务。

Redis的分布式机制为原子层的，针对每一个建立的任务都一个争抢锁，也就是任务和争抢锁一一对应。对于选定的任务，争抢锁只能被一个服务占用，争抢锁列表只有所有争抢锁的信息，例如锁的id、名称、占用状态等等。

在一种可能的实施方式中，一个定时任务触发后，多个服务之间按照时间先后响应来占用争抢锁，那么只有最快响应的服务会占用，并将其作为目标任务。但在多任务情况下，还需要对附加条件进行判定，也就是存在关联任务的情况，因为关联任务大多需要前序条件，只有前序条件完成的情况下才能正常执行该任务。因而本方案在确定目标任务时还充分考虑了每个任务的前序条件完成情况，以此来避免争抢失败和无效争抢的情况。

步骤104，对目标任务创建子任务线程，并放到本地线程池中异步执行和同步redis缓存。

任务核心线程用于相应任务，在确定执行任务后，通过建立该任务的子任务线程，转由子任务线程在本地线程池中异步执行该目标任务，在执行完成后，实时更新redis缓存和其中的参数信息。用于后续循环操作需要。在大数据调度方案场景下，对于这种多服务的汇总任务，严格按时间触发，并根据争抢锁机制来执行。同时针对存在关联任务进行前序条件查验，在满足执行条件的情况下才会争抢确定，且建立的目标任务转由子任务线程执行，这样可以避免io占用和数据库锁死的情况的发生。

综上，本申请通过在集群服务器中引入redis缓存机制，实时根据数据库内容更新redis缓存内容，并按照所建任务的争抢锁状态和条件完成情况来选择目标任务，特别是在多任务触发条件下，可以确保每个任务都具有时间上的连贯性，且不会被重复占用和执行。而关联性任务之间则按照前序条件来进行筛选，避免关联任务被重复占用执行，确保任务顺利执行。采用任务核心线程和任务子线程分离执行的机制，可以大幅提高批量任务下的并发率，大幅减少数据库io占用。同时还是负载每一个任务到不同服务内，通过配置线程池能够调整每个服务最大任务数灵活配置使任务分配更优充分使用服务器资源。使用该方案后完美消除了数据库io瓶颈。

图2是本申请另一实施例提供的应用系统多服务集群下定时任务调度方法的流程图，包括如下步骤：

步骤201，接收指令创建任务，将任务对应数据存入数据库并同步到redis缓存中。

步骤202，轮询任务列表，根据定时信息确定新触发任务，根据任务当前状态、争抢锁id及争抢状态、任务重试次数及最大重试次数确定可执行任务。

任务列表中包含所有创建且未执行完毕的任务，redis缓存中还包含有任务列表对应的争抢锁列表；争抢锁列表包括所有服务对任务的争抢状态。

状态信息至少包括每个任务的争抢锁id、任务id、任务参数、定时信息、执行类名、任务重试次数及最大重试次数、任务当前状态、前序任务列表和后续任务列表。前序任务列表和后续任务列表中包含有执行该任务需要的前序任务和后续任务。定时信息为触发该任务争抢机制的时间。

任务核心线程启动并完成数据同步后，会轮询任务列表中所有的任务，根据当前系统时间和任务定时信息的时间确定新触发任务，也就是定时触发。同时为提高系统容错性，针对历史进程中执行失败的任务，也会采用重试机制再次执行，这些历史任务具体根据任务当前状态、争抢锁id及争抢状态、任务重试次数及最大重试次数确定，也就是可执行任务。因为任务和争抢锁是一一映射的，每个任务都对应有各自的执行状态，如未执行和正在执行，而争抢锁也对应分为未占用和已占用状态，占用是指被集群中的某个服务占用，也就是任务核心线程。

步骤203，基于可执行任务和新触发任务更新可执行任务列表。

可执行任务列表根据可执行任务和新触发任务更新实时更新。

步骤204，核对可执行任务列表中各个候选任务对应前序任务的完成状态，并将前序任务未完成的候选任务滤除，获得中间任务列表。

组成的候选任务原则上都可以正常执行，但对于一些存在关联性的任务，其本身会涉及到多项任务执行，所以需要对前序和后续任务进行核验，前序任务就是执行该任务前，需要确保与之关联的前序任务执行完毕，依托前序任务产生的中间数据来执行，否则该任务无法正常执行完毕。前序任务列表和后续任务列表可在redis内提前执行，且一个任务可以包含有多项前序任务或后续任务，必须保证前序任务都已经完成才能参与后续锁的争抢。

同理，后续任务同样如此，需要借助本次执行结果执行后续任务。所以此步骤要初步的核验前序任务。对于那些还未执行前序任务的候选任务就需要滤除，滤除后的任务集合即为中间任务列表。当然，对于本身不存在前序任务和后续任务的不需要滤除。

步骤206，基于redis分布式机制对所有中间任务执行多任务争抢，将争抢到的中间任务作为目标任务，同步更新目标任务的任务重试次数、执行信息时间、以及最晚完成时间。

redis争抢锁的原理是基于原子性的，也就是将所有服务任务按照设定规则争抢任务，各个服务会查询任务对应争抢锁的状态，当处于未占用状态时，会将其占用，同时将状态修改为已占用，这样在其他任务查询到该已占用状态时直接跳过，这样就可以保证一个任务只能被一个服务执行。对于一个选定的服务的任务核心进程，在争抢到后会将其确定为目标任务，并同步更新目标任务的任务重试次数、执行信息时间、以及最晚完成时间。

步骤207，对目标任务创建子任务线程，并在本地线程池中执行。

子任务线程和任务核心线程分属不同线程池，任务核心线程是常驻线程池，用于调度和承担各个任务的实现，而全局线程池用于子任务线程的创建和调度，任务核心线程的数量可以规定如3个或多个，异步轮询执行各个任务的争抢。具体如图3所示。

步骤208，根据任务参数执行内容，并记录日志信息。

步骤209，执行完成后根据结果更新redis缓存中的任务列表，用于任务核销。

对于已经执行完成的任务，就需要及时对redis缓存更新，方便后续任务核心线程执行争抢任务。且线程数的调度根据数据量的多少决定。

特别的，对于一些存在后续任务的目标任务，同样需要执行后续任务，子任务线程继续通过redis缓存读取后续任务列表和可执行任务列表，继续通过争抢锁执行后续任务。

图3是本申请实施例提供的应用系统多服务集群下定时任务调度方法的算法流程图。具体包括如下步骤：

步骤1.存入数据库并同步到redis缓存。

redis缓存中存有该任务对应的锁的id、后续任列表、任务参数、任务名称、任务执行类名、任务重试次数、任务最大重试次数、前序任务列表、任务当前状态、最晚完成时间、任务id、定时信息等。

步骤2.对比数据和缓存是否一致。

一致时直接执行步骤4，否则执行步骤3调取数据库更新。

步骤3.同步缓存与数据库。

步骤4.查询可执行任务信息和超时任务信息并放入可执行任务列表。

此处的超时任务信息即为争抢锁状态为执行中，但按照执行信息时间你，且到最晚完成时间后未完成的任务，这就需要强制解锁，将争抢锁重新设置为未占用状态，同时更新任务重试次数。当任务重试次数未超过最大重试次数时，则需要将其放到可执行任务列表中，在后续过程中继续参与锁的争抢。对于那些最大重试次数的任务选择放弃执行，避免过度浪费服务器资源。

步骤5.获取可执行任务列表，任务争抢并且核对任务前序条件完成情况。

步骤6.对争抢到的任务进行创建并放入本地线程池异步执行。

该步骤跳转到步骤8的任务子线程中进行。

步骤7.核心线程休眠。

任务核心线程的数量是设定好的，在每次执行争抢和选定目标任务后，都需要短暂休眠，避免CPU锁死。休眠完成后继续跳转到步骤5执行争抢锁的环节。

步骤8.任务执行并记录日志信息。

步骤9.执行完成后根据结果更新缓存。

步骤10.如果执行成功判断是否有后续任务如果有就更新缓存。

对于有后续任务列表的情况，则继续从redis缓存中读取后续任务，继续调度任务核心线程执行创建任务。否则子线程休眠。

这种采用任务核心线程和任务子线程分离的调度方案，可以高效利用服务器资源，避免io高占用和CPU锁死的问题，特别是高并发任务场景下，系统处理依然可以保持流畅运行。

以上对本发明的较佳实施例进行了描述；需要理解的是，本发明并不局限于上述特定实施方式，其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施；任何熟悉本领域的技术人员，在不脱离本发明技术方案作出许多可能的变动和修饰，或修改为等同变化的等效实施例，这并不影响本发明的实质内容；因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。

Claims (1)

1.一种应用系统多服务集群下定时任务调度方法，其特征在于，所述方法包括：

接收指令创建任务，将任务对应数据存入数据库并同步到redis缓存中；

任务核心线程启动并完成数据同步后，查询所述redis缓存的任务列表，根据任务列表中各任务的状态信息更新可执行任务列表；其中，任务列表中包含有所有创建且未执行完毕的任务和对应状态信息，所述可执行任务列表中包含有任务核心线程确定的具备执行条件的任务；所述redis缓存还包含有任务列表对应的争抢锁列表，所述争抢锁列表包括所有服务对任务的争抢状态；所述状态信息至少包括每个任务的争抢锁id、任务id、任务参数、定时信息、执行类名、任务重试次数及最大重试次数、任务当前状态、前序任务列表和后续任务列表；所述前序任务列表和所述后续任务列表中包含有执行该任务需要的前序任务和后续任务；所述定时信息为触发该任务争抢机制的时间；更新所述可执行任务列表具体包括：

轮询所述redis缓存的任务列表，根据所述定时信息确定新触发任务，根据任务当前状态、争抢锁id及争抢状态、任务重试次数及最大重试次数确定可执行任务；

基于可执行任务和新触发任务更新所述可执行任务列表；其中，可执行任务为历史执行失败的任务，且执行次数小于最大重试次数，集群服务器包含若干服务，所述可执行任务列表中的任务对应争抢锁状态为未占用状态，任务当前状态为未执行状态；

更新所述可执行任务列表后，基于任务类型和任务参数对所述可执行任务列表中的所有任务进行归类，将存在关联条件的任务建立各自的所述前序任务列表及所述后续任务列表；

基于redis分布式机制获取所述可执行任务列表对应的任务锁争抢列表，通过争抢锁机制和任务的前序条件完成情况确定目标任务；具体包括：

核对所述可执行任务列表中各个候选任务对应前序任务的完成状态，并将前序任务未完成的候选任务滤除，获得中间任务列表；

基于redis分布式机制对所有中间任务执行多任务争抢，将争抢到的所述中间任务作为所述目标任务，同步更新所述目标任务的任务重试次数、执行信息时间、以及最晚完成时间；

当所述目标任务在最晚完成时间内未完成执行任务时，争抢锁自动失效；所述执行信息时间为目标服务争抢到锁的时间，且抢到锁后的争抢锁更新为已占用状态；其中，任务核心线程移交任务到本地线程池中执行后进入休眠状态，休眠完成后继续获取当前的所述中间任务列表；当所述中间任务列表不存在满足执行条件的任务时结束线程，否则继续根据所述中间任务列表执行争抢任务；

对所述目标任务创建子任务线程，并放到本地线程池中异步执行和同步所述redis缓存，子任务线程和任务核心线程分属不同线程池，任务核心线程是常驻线程池，用于调度和承担各个任务的实现，全局线程池用于子任务线程的创建和调度，具体包括：

对所述目标任务创建子任务线程，并在本地线程池中执行；

根据任务参数执行内容，并记录日志信息；

执行完成后根据结果更新所述redis缓存中的任务列表，用于任务核销；

当所述目标任务包含有所述后续任务列表时，读取并更新所述redis缓存中任务列表和所述可执行任务列表，继续通过争抢锁执行后续任务。