CN110377410A - 任务调度方法、系统、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种任务调度方法、系统、电子设备及计算机可读存储介质，应用于任务调度领域，其中该方法包括：接收任务请求；根据请求向业务端发起调度任务请求；当调度任务请求失败时，发起重试请求，并发出调度失败信息；当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数超过阈值时，停止发起调度任务。本发明通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。通过在调度中心中对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。

Description

任务调度方法、系统、电子设备及计算机可读存储介质

技术领域

本申请涉及任务调度领域，具体而言，本申请涉及一种任务调度方法、装置、电子设备及计算机可读存储介质。

背景技术

无论是互联网应用或者企业级应用，都充斥着大量的批处理任务。常常需要一些任务调度系统帮助开发者解决问题。随着服务化架构的逐步演进，单体架构逐渐演变为分布式、微服务架构。在此背景下，很多原先的任务调度平台已经不能满足业务系统的需求，尤其是在银行体系中，随着直销银行和互联网系统繁多，而每个内部系统都有定时调度的业务需求，各系统独立维护定时任务不利于业务系统的稳定性，也不利于管理；银行的日切、对账、计结息等场景都是离线任务，对准确性，容错性要求高；目前的调度平台均不能满足上述需求，一旦发生宕机会影响线上业务，容易造成资金损失等一系列问题。

发明内容

为了解决上述问题申请人提供了一种任务调度方法、系统、电子设备及计算机可读存储介质，用于解决在线任务调度失败后，如何在离线模式下继续调度任务并通知任务请求主体的问题，本申请采用的技术方案如下：

第一方面，提供了一种任务调度方法，该方法包括，

接收任务请求；

根据请求向业务端发起调度任务请求；

当调度任务请求失败时，发起重试请求，并发出调度失败信息；

当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数超过阈值时，停止发起调度任务。

在上述方法中，在调度任务失败的情况下，即使发起重试请求，一旦重试异常，将在离线模式下继续重试，保证了调度任务的稳定执行。但无限制的重试将浪费计算资源，必须有一个阈值限定，当重试的次数超过阈值后，即刻停止发起调度任务。

进一步地，为了限定重试请求的具体方式，所述重试请求中还包含如下参数的一种或多种：

重试延时执行时间，为距离首次调度任务失败的时间；

重试间隔时间，为重试请求之间的间隔时间；

可重试的异常，为反馈的执行异常被纳入可重试的范围内。

进一步地，为了使得每一个任务都有对应的重试请求，所述重试请求以注释名称的方式与所述任务对应，一般将任务的名称含在重试请求注释名称中，并存储于数据库中。

进一步地，为了实现调度端与业务端的连接，有效地发出任务调度指令，发起调度任务前，建立接口与所述业务端的所述任务实现接口方法的连接。

进一步地，为了解决新类型任务调度的问题，当出现新任务的调度请求时，发起添加所述新任务调度方法请求，将新任务的相关信息添加到所述数据库，再发起调度请求；

新任务的实现接口方法通过接口以反射方式获取，反射方式可以参照Java编程中用到的反射方式，并将新任务的实现接口方法存储于所述数据库中。

进一步地，为了系统地管理每一个任务的调度，所述任务的相关信息由执行器管理，一个执行器对应多个批量任务信息。

现阶段的系统大多是分布式设计，同一个系统多个节点之间要保证调度的唯一性，为解决分布式调度的问题，在发起调度任务时，判断所述任务是否为分片模式:

在不是分片模式的情况下，直接调度任务；

在分片模式下，获取所述任务的路由模式，根据所述路由模式调度任务。

第二方面，提供了一种任务调度系统，包括：

调度中心模块，用于接收任务请求，根据请求向业务端发起调度任务请求，当调度任务请求失败时，发起重试请求，并发出调度失败信息；当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数符合阈值时，停止发起调度任务；

执行管理模块，用于管理所述任务的相关信息，包含多个执行器，一个执行器对应多个批量任务信息；

数据库，用于存储任务相关信息及所述重试请求信息；

接口模块，向业务端提供调度任务的接口。

第三方面，提供了一种电子设备，包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，一个或多个程序配置用于：执行根据权利要求第一方面的任务调度方法。

第四方面，提供了一种计算机可读存储介质，计算机存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机可以执行第一方面的任务调度方法。

本申请提供了一种任务调度方法、装置、电子设备及计算机可读存储介质，与现有技术相对单一的调度方式相比，本申请通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。在任务调度的过程中，根据任务的分布式设置模式，判断是任务是否是分片的模式，进而按照分片的路由方式进行任务调度，保证了分布式任务调度的顺利实施，无需担心单点调度系统不够健壮，宕机影响业务的问题。并且能在调度中心对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

图1为本申请实施例的一种任务调度方法的流程示意图

图2为本申请实施例的一种任务调度系统结构示意图

图3为本申请实施例的一种任务调度电子设备结构示意图

具体实施方式

下面详细描述本申请的实施例，各实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

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

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

本申请实施例提供了一种任务调度方法，如图1所示，该方法可以包括以下步骤：

步骤S101，接收任务请求；

具体地，调度中心接收客户端或者业务端的任务请求，示例性的，接收的为提现任务请求。客户端可以来自PC端，也可以来自移动端，其中，该终端设备可以是手机、PAD、计算机终端等，此处不做限定。

步骤S102，根据所述任务请求向业务端发起调度任务请求；

若接收的提现请求，调度中心则向银行系统发起调度提现任务请求。

步骤S103，当调度任务请求失败时，发起重试请求，并向任务发出主体发出调度失败通知；

具体地，当提现任务调度失败时，重新发起调度提现任务请求，并向客户端发出调度失败的通知；

步骤S104，当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数超过阈值时，停止发起调度任务。

示例性地，当方法recharge输入参数为“retry”时，会抛出Exception异常，此时会触发方法重试。

本申请实施例与现有技术相对单一的调度方式相比，通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。在任务调度的过程中，根据任务的分布式设置模式，判断是任务是否是分片的模式，进而按照分片的路由方式进行任务调度，保证了分布式任务调度的顺利实施，无需担心单点调度系统不够健壮，宕机影响业务的问题。并且能在调度中心对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。

本申请实施例提供了另一种可能的实现方式，进一步地，在上述步骤S103中，针对需要中断重试的方法，在方法头添加注释Retry Call Back(Retry Call Back参数包括以下参数的那个或多种，

perform Delay Time重试方法延时执行时间,单位毫秒

max Retry Times最大重试次数；

interval Time重试间隔时间,单位毫秒；

retry Exceptions可重试的异常)。

具体地，编码为：

示例性地，重试规则是，一分钟后执行，最多执行三次，每次间隔1秒，重试3次依然异常，则停止发起调度任务。

对于本申请的实施例，进一步地解决了限定重试请求的具体方式的问题，可以针对不同的调度任务设置不同的重试机制，灵活地是用于多种场景。

本申请实施例提供了另一种可能的实现方式，进一步地，在步骤S102前，建立调度端接口与业务端实现调度端接口方法的连接。

示例性地，接口由调度端提供，至于如何实现接口的方法，由业务端根据自身的特点自行开发。

对于本申请的实施例，进一步地解决了有调度需求的业务端通过自行开发建立和调度端连接的问题。使得调度端成为一个开放的平台，但凡有意愿由调度端对自己进行调度，免除系统自行调度的困扰的，都可以连接调度端。

本申请实施例提供了另一种可能的实现方式，该方法还包括：

步骤S104(图中未示出)，当出现新任务的调度请求时，发起添加所述新任务调度方法请求，

步骤S105(图中未示出)，将新任务的相关信息添加到所述数据库，再发起调度请求；

新任务的实现接口方法通过接口以反射方式获取，反射方式可以参照Java编程中用到的反射方式，并将新任务的实现接口方法存储于所述数据库中。

示例性的，调度中心现存的业务并不包括转账，现出现了一种新的任务请求——转账，首先通过HTTP页面发起添加转账任务调用的方法请求，把相应的数据添加到数据库后调用，通过Job Dynamic Scheduler中的add Job方法添加任务，通过反射获取到转账业务端实现调度端接口方法。

对于本实施例，解决了新类型任务调度添加的问题，为实现调度中心可以集中管理所有任务调度提供了途径。

本申请实施例提供了另一种可能的实现方式，任务的相关信息由执行器管理，一个执行器对应多个批量任务信息。

具体的任务的相关信息包括：任务ID、路由策略、运行模式、任务参数、阻塞处理策略、负责人、任务描述、失败处理策略等。

对于本实施例，解决了有体系地管理每一个任务的调度的问题，并且能够追索到每一个调度任务的具体信息，使得整个调度过程更加有条理。

本申请实施例提供了另一种可能的实现方式，在步骤S102中，发起调度任务时，要判断所述任务是否为分片模式:

在不是分片模式的情况下，直接调度任务；

在分片模式下，获取所述任务的路由模式，根据路由模式调度任务。

示例性地，发起结算任务的调度时，判断结算任务的路由模式，由于结算任务的数据量通常较大，在业务端由不同的子节点分别执行，根据结算任务路由模式设定的具体分片模式，去特定的子节点发布调度结算任务指令。

对于本实施例，解决了分布式调度的问题，适应互联网银行系统的分布式设计，保证了同一个系统多个节点之间要调度的唯一性。

图2为本申请实施例提供的一种任务调度系统，该系统20，包括：

调度中心模块201，用于接收任务请求，根据请求向业务端发起调度任务请求，当调度任务请求失败时，发起重试请求，并发出调度失败信息；当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数符合阈值时，停止发起调度任务；

执行管理模块202，包含多个执行器，用于管理所述任务的相关信息，一个执行器对应多个批量任务信息；

数据库203，用于存储任务相关信息及所述重试请求信息；

接口模块204，向业务端提供调度任务的接口。

具体地使用方式为：

通过管理后台登陆，配置执行器。执行管理页面进入之后显示当前所有的执行器以列表的形式展示。点击新增按钮弹出新增执行器框，根据页面显示的列添加数据库点击提交保存到数据库中。每个业务对应一个执行器，一个执行器可以对应多个批量任务。

实现类加上注解@JobHandler(value＝"name")，指定名字。

管理后台新增任务，在列表页面点击右上角的新增任务弹出新增页面。填写相应的值点击保存把当前的任务添加到数据库。支持按条件检索、新增任务、以及对当前某一个任务进行相应的操作(包含执行、恢复、日志、编辑、删除等)。

该系统启动时会扫加了@RetryCallBack注释的方法，把这些方法加载到本地内存集合中，然后通过redis分布式锁抢任务，抢到锁的机器循环集合调用重试系统接口查询是否有需要执行的任务(重试次数没有达到最大次数并且没有执行成功的)，如果有就把任务的id加载到本地内存的延迟队列中；

对加了@RetryCallBack注释的方法，当方法执行抛出对应的异常时，该系统会捕获到此异常，然后将本次执行的参数和具体重试的时间、次数通过http restful接口持久化到系统数据库；

同时将这条记录的任务id和出发时间保存在内存中的延迟队列中；

队列中有任务后会一直轮训队列是否有到期的重试任务，如果有就拿记录id去重试系统数据库查出相应的参数进行重试，重试成功或者超出最大次数则从队列中移除，否则一直轮训直到队列中没有任务为止。

本申请实施例与现有技术相对单一的调度方式相比，通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。在任务调度的过程中，根据任务的分布式设置模式，判断是任务是否是分片的模式，进而按照分片的路由方式进行任务调度，保证了分布式任务调度的顺利实施，无需担心单点调度系统不够健壮，宕机影响业务的问题。并且能在调度中心对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。

本申请实施例提供了一种任务调度系统，适用于上述实施例所示的方法，在此不再赘述。

本申请实施例提供了一种电子设备，如图3所示，图3所示的电子设备30包括：处理器3001和存储器3003。其中，处理器3001和存储器3003相连，如通过总线3002相连。进一步地，电子设备30还可以包括收发器3004。需要说明的是，实际应用中收发器3004不限于一个，该电子设备300的结构并不构成对本申请实施例的限定。其中，处理器3001应用于本申请实施例中，用于实现图2所示的调度中心模块、执行管理模块、数据以及接口的功能，收发器3004包括接收机和发射机。

处理器3001可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器3001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线3002可包括一通路，在上述组件之间传送信息。总线3002可以是PCI总线或EISA总线等。总线3002可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器3003可以是ROM或可存储静态信息和指令的其他类型的静态存储设备，RAM或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM、CD-ROM或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器3003用于存储执行本申请方案的应用程序代码，并由处理器3001来控制执行。处理器3001用于执行存储器3003中存储的应用程序代码，以实现图2所示实施例提供的任务调度系统的功能。

本申请实施例提供了一种电子设备，与现有技术相对单一的调度方式相比，通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。在任务调度的过程中，根据任务的分布式设置模式，判断是任务是否是分片的模式，进而按照分片的路由方式进行任务调度，保证了分布式任务调度的顺利实施，无需担心单点调度系统不够健壮，宕机影响业务的问题。并且能在调度中心对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。本申请实施例提供了一种电子设备适用于上述方法实施例。在此不再赘述。

本申请实施例提供了一种电子设备，适用于上述实施例所示的方法，在此不再赘述。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述实施例中所示的方法。

本申请实施例提供了计算机可读存储介，与现有技术相对单一的调度方式相比，通过调度任务失败后，重试请求方法进行细化设置，继而保证了调度任务在离线模式下依然能够继续进行，顺利的完成调度任务。在任务调度的过程中，根据任务的分布式设置模式，判断是任务是否是分片的模式，进而按照分片的路由方式进行任务调度，保证了分布式任务调度的顺利实施，无需担心单点调度系统不够健壮，宕机影响业务的问题。并且能在调度中心对调度的任务进行统一监管，避免了由各系统独立维护调度任务导致业务系统的稳定性差的问题。

本申请实施例提供了一种计算机可读存储介质适用于上述方法实施例。在此不再赘述。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种任务调度方法，其特征在于，包括如下步骤：

接收任务请求；

根据所述任务请求向业务端发起调度任务请求；

当调度任务请求失败时，发起重试请求，并发出调度失败信息；

当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数超过阈值时，停止发起调度任务。

2.根据权利要求1所述的任务调度方法，其特征在于，所述重试请求中还包含如下参数的一种或多种：

重试延时执行时间，为距离首次调度任务失败的时间；

重试间隔时间，为重试请求之间的间隔时间；

可重试的异常，为反馈的执行异常被纳入可重试的范围内。

3.根据权利要求2所述的任务调度方法，其特征在于，所述重试请求以注释名称的方式与所述任务对应，存储于数据库中。

4.根据权利要求1所述的任务调度方法，其特征在于，发起所述调度任务请求前，建立接口与所述业务端的所述任务实现接口方法的连接。

5.根据权利要求4所述的任务调度方法，其特征在于，当出现新任务的调度请求时，发起添加所述新任务调度方法请求，将新任务的相关信息添加到所述数据库，再发起调度请求；

所述新任务的实现接口方法通过所述接口以反射方式获取，并将所述新任务的实现接口方法存储于所述数据库中。

6.根据权利要求1所述的任务调度方法，其特征在于，所述任务的相关信息由执行器管理，一个执行器对应多个批量任务信息。

7.根据权利要求1所述的任务调度方法，其特征在于，发起调度任务时，判断所述任务是否为分片模式:

在不是分片模式的情况下，直接调度任务；

在分片模式下，获取所述任务的路由模式，根据所述路由模式调度任务。

8.一种任务调度系统，其特征在于，包括：

调度中心模块，用于接收任务请求，根据请求向业务端发起调度任务请求，当调度任务请求失败时，发起重试请求，并发出调度失败信息；当重试请求执行异常时，由在线模式转为离线模式，重新发起所述重试请求，当重试请求次数符合阈值时，停止发起调度任务；

执行管理模块，用于管理所述任务的相关信息，包含多个执行器，每一个所述执行器对应多个批量任务信息；

数据库，用于存储所述任务相关信息及所述重试请求信息；

接口模块，向所述业务端提供调度任务的接口。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行根据权利要求1至7任一项所述的任务调度方法。

10.一种计算机可读存储介质，其特征在于，所述计算机存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机可以执行上述权利要求1至7中任一项所述的任务调度方法。