具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

现有技术中，业界的任务调度系统在依赖配置和检测这块，一般都是按照场景来支持依赖配置，灵活度不够。一般支持的依赖策略都较少，例如仅支持同周期依赖，小周期依赖大周期等，一般只能解决90％的业务场景，对于其他10％的业务场景，则无法解决，支持的业务场景有限，灵活性较差。

为了解决上述技术问题，本申请实施例提供了一种任务调度方法及装置。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的任务调度方法进行详细地说明。

图1是本申请实施例提供的一种任务调度方法的流程图，如图1所示，该方法可以包括以下步骤：步骤101、步骤102、步骤103、步骤104和步骤105，其中，

在步骤101中，获取上游任务和下游任务，其中，下游任务的执行依赖于上游任务。

本申请实施例中，上游任务和下游任务均为定时执行的周期任务。上游任务和下游任务的执行周期可以相同；或者，上游任务的执行周期可以大于下游任务的执行周期；或者，上游任务的执行周期可以小于下游任务的执行周期。

本申请实施例中，上游任务和下游任务可以为预先生成的任务，在获取上游任务和下游任务时，直接获取预先生成的上游任务和下游任务；或者，上游任务和下游任务可以为实时生成的任务，在获取上游任务和下游任务时，获取上游任务的第一业务逻辑和下游任务的第二业务逻辑，根据第一业务逻辑生成上游任务，以及根据第二业务逻辑生成下游任务。

本申请实施例中，上游任务的个数可以为1个，也可以为多个。

为了便于理解，在一个例子中，当上游任务的个数为多个时，如图2所示，定义任务A、任务B和任务C三个周期任务，任务A和任务B是上游任务，任务C是下游任务；

其中，任务A的业务逻辑为：任务A是每天调度的任务，调度时间为每天上午9时；任务B的业务逻辑为：任务B是每小时调度的任务，调度时间为每小时的30分；任务C的业务逻辑为：任务C是每天调度的任务，调度时间为每天下午17时。

在步骤102中，配置下游任务的依赖信息，其中，依赖信息中包含上游任务的标识、依赖上游任务的时间范围和依赖上游任务的实例个数。

本申请实施例中，上游任务的标识可以为上游任务的名称。

本申请实施例中，为避免时间范围设置时出现混淆，可以通过预设时间表达式配置依赖信息中的时间范围，也就是，通过预设时间表达式来配置依赖上游任务的时间范围，例如本申请实施例中表1所示的时间表达式(后续为了便于理解，时间范围均以表1中时间表达式为例进行描述)。

本申请实施例中，上游任务每执行一次，为一个上游任务的实例。在配置依赖上游任务的实例个数时，可以为上游任务的所有实例，也可以为具体的实例个数，也可以为占实例总数的百分比。

本申请实施例中，为了便于用户操作，可以提供专门的依赖信息配置页面，用户可以在该配置页面内输入相应的依赖信息，此时，上述步骤102具体可以包括以下步骤(图中未示出)：步骤1021、步骤1022和步骤1023，其中，

在步骤1021中，显示依赖信息配置页面，其中，该依赖信息配置页面上显示以下三个设置项目：依赖任务标识设置项、依赖时间范围设置项和依赖实例个数设置项。

在步骤1022中，接收用户在三个设置项目中输入的信息。

在步骤1023中，将用户输入的信息设置为下游任务的依赖信息。

本申请实施例中，依赖任务标识设置项用于接收用户输入的依赖上游任务的标识，依赖时间范围设置项用于接收用户输入的依赖上游任务的时间范围，依赖实例个数设置项用于接收用户输入的依赖上游任务的实例个数。

在一个例子中，接步骤101中的例子，由于任务C的执行依赖于任务A和任务B，因此在任务C上配置依赖信息(也可称为“依赖策略”)，如图3所示，依赖信息配置页面中可以包含三个参数设置项目：依赖任务标识设置项“依赖任务名称”、依赖时间范围设置项“依赖时间范围设置”和依赖实例个数设置项“依赖实例个数”。

首先，在“依赖任务名称”中分别输入任务A和任务B的名称；

之后，在“依赖时间范围设置”中分别输入对应任务的依赖时间范围，具体的，依赖任务A的时间范围为0dB至0dE，依赖任务B的时间范围为-1dB至-1dE，其中，0dB标识基于当前任务实例的调度时间(例如今天17时43分40秒)往前推0天后这天的开始(也就是今天0时0分0秒)，0dE则代表今天的结束时间(今天23时59分59秒)。同理，-1dB，-1dE表示昨天的开始和昨天的结束时间，具体时间表达式的实现见表1。

最后，在“依赖实例个数”中分别输入依赖的实例个数，具体的，依赖任务A的实例个数为所有，依赖任务B的实例个数为12个。

在步骤103中，根据依赖信息，确定上游任务的执行情况。

本申请实施例中，在配置完下游任务的依赖信息之后，根据已配置的依赖信息进行依赖检测，也就是，检测上游任务的执行情况。

本申请实施例中，在检测上游任务的执行情况时，主要是检测在依赖上游任务的时间范围内，上游任务执行成功的次数，也就是，执行成功的上游任务的实例个数。

在一个例子中，接步骤102中的例子，对于任务A，检测在(0dB，0dE)时间内，任务A执行成功的次数；对于任务B，检测在(-1dB，-1dE)时间内，任务B执行成功的次数。

在步骤104中，根据上游任务的执行情况，确定上游任务在上述时间范围内执行成功的实例个数是否不小于依赖信息中配置的实例个数。

在步骤105中，若上游任务在上述时间范围内执行成功的实例个数不小于依赖信息中配置的实例个数，则确定上游任务处于依赖检测通过状态，执行下游任务。

在一个例子中，接步骤103中的例子，以下流程基于2021-06-09 17:00:00这个调度时间的任务C执行记录来说明。

对于任务A的依赖检测，任务C依赖任务A从今天开始到结束(2021-06-09 00:00:00～2021-06-09 23:59:59)这段时间内所有任务A的执行都要成功。由于任务A配置的是每天上午9时执行，所以在这个时间范围内，只有一次执行记录，则只需要检测任务A今天9时的这次执行是否成功了即可，只要这次成功了，则说明对任务A的依赖检测通过了。

对于任务B的依赖检测，任务C依赖任务B从昨天开始到昨天结束(2021-06-08 00:00:00～2021-06-08 23:59:59)这段时间内至少12次任务B执行成功即可。而任务B是每小时调度，所以昨天开始到昨天结束这段时间内是有24次执行，我们只需要检查这24次执行是否有不低于12次执行成功，如果有，则说明对任务B的依赖检测通过了。

当任务A和任务B的依赖检测均通过之后，则执行任务C。

本申请实施例中，若上游任务在上述时间范围内执行成功的实例个数小于所述依赖信息中配置的实例个数，则确定上游任务处于依赖检测不通过状态，等待下一次检测，直至确定上游任务处于依赖检测通过状态，执行下游任务。其中，对于依赖检测不通过的情况，可以定时触发下一次依赖检测，或者在上游任务完成后触发下游任务检测，以通过两种机制保障依赖检测的速度和可靠性。

由上述实施例可见，该实施例中，在获取上游任务和下游任务之后，配置下游任务的依赖信息，其中，依赖信息中包含上游任务的标识、依赖上游任务的时间范围和依赖上游任务的实例个数；根据依赖信息，确定上游任务的执行情况；根据执行情况，确定上游任务在上述时间范围内执行成功的实例个数是否不小于依赖信息中配置的实例个数，若是，则确定上游任务处于依赖检测通过状态，执行下游任务。与现有技术相比，本申请实施例中，在配置下游任务的依赖策略时，通过在依赖策略中加入依赖上游任务的时间范围参数，来建立上游任务与下游任务的依赖关系，基于所配置的依赖策略进行任务依赖检测，可以支持各种类型的业务场景，灵活性较高。

基于本申请实施例中的任务依赖信息配置方法，可以实现所有业务场景下任务的依赖配置，为了便于理解，通过以下多种业务场景进行举例说明：

针对于自依赖的业务场景：当任务A每天上午9时调度，需要依赖昨天和前天执行的结果时，可进行如图4所示的依赖信息配置。

针对于小周期任务依赖大周期任务的业务场景：

当任务A每天9时调度，任务B每小时30分调度，任务B依赖任务A昨天执行的结果时，可进行如图5所示的依赖信息配置。

当任务A每天9时调度，任务B每小时30分调度，任务B依赖任务A今天执行的结果时，可进行如图6所示的依赖信息配置。

针对于大周期任务依赖小周期任务的业务场景：

当任务A每小时30分调度，任务B每天9时调度，任务B依赖任务A昨天最后一次执行的结果时，可进行如图7所示的依赖信息配置。

当任务A每小时30分调度，任务B每天9时调度，任务B依赖任务A昨天12时到18时之间执行的结果时，可进行如图8所示的依赖信息配置。

当任务A每小时30分调度，任务B每天9时调度，任务B依赖任务A昨天执行结果，任务A只要执行成功一次即可时，可进行如图9所示的依赖信息配置。

可见，本申请实施例中，通过引入额外的几个参数，尤其是时间范围配置，可以增强依赖配置的能力，可以实现100％的依赖场景配置。

表1示出了本申请实施例提供的一种时间表征形式。

表1

在一个基于表1的例子中，“2d+2w-2mB-2dE”表示：当前时间(任务调度中的调度时间)加上两天，再加上两周，再减去两个月并将时间设置为该月月初(例如1月，就是1月1日0时0分0秒)，然后再往前两天并将时间设置为当天结束时间(例如24号，那时间就是24号23时59分59秒)。通过以上规则就可以算出基于当前时间(调度时间)的任何一个时间点。

需要说明的是，本申请实施例提供的任务调度方法，执行主体可以为任务调度装置，或者该任务调度装置中的用于执行加载任务调度方法的控制模块。本申请实施例中以任务调度装置执行加载任务调度方法为例，说明本申请实施例提供的任务调度装置。

图10是本申请实施例提供的一种任务调度装置的结构框图，如图10所示，任务调度装置1000，可以包括：获取模块1001、配置模块1002、第一确定模块1003、第二确定模块1004和执行模块1005，其中，

获取模块1001，用于获取上游任务和下游任务，其中，所述下游任务的执行依赖于所述上游任务；

配置模块1002，用于配置所述下游任务的依赖信息，其中，所述依赖信息中包含所述上游任务的标识、依赖所述上游任务的时间范围和依赖所述上游任务的实例个数；

第一确定模块1003，用于根据所述依赖信息，确定所述上游任务的执行情况；

第二确定模块1004，用于根据所述执行情况，确定所述上游任务在所述时间范围内执行成功的实例个数是否不小于所述依赖信息中配置的实例个数；

执行模块1005，用于在所述确定模块的确定结果为是的情况下，确定所述上游任务处于依赖检测通过状态，执行所述下游任务。

由上述实施例可见，该实施例中，在获取上游任务和下游任务之后，配置下游任务的依赖信息，其中，依赖信息中包含上游任务的标识、依赖上游任务的时间范围和依赖上游任务的实例个数；根据依赖信息，确定上游任务的执行情况；根据执行情况，确定上游任务在上述时间范围内执行成功的实例个数是否不小于依赖信息中配置的实例个数，若是，则确定上游任务处于依赖检测通过状态，执行下游任务。与现有技术相比，本申请实施例中，在配置下游任务的依赖策略时，通过在依赖策略中加入依赖上游任务的时间范围参数，来建立上游任务与下游任务的依赖关系，基于所配置的依赖策略进行任务依赖检测，可以支持各种类型的业务场景，灵活性较高。

可选地，作为一个实施例，所述配置模块1002，可以包括：

显示子模块，用于显示依赖信息配置页面，其中，所述依赖信息配置页面上显示以下三个设置项目：依赖任务标识设置项、依赖时间范围设置项和依赖实例个数设置项；

接收子模块，用于接收用户在所述三个设置项目中输入的信息；

设置子模块，用于将用户输入的信息设置为所述下游任务的依赖信息。

可选地，作为一个实施例，所述获取模块1001，可以包括：

获取子模块，用于获取第一业务逻辑和第二业务逻辑；

生成子模块，用于根据所述第一业务逻辑生成上游任务，以及根据所述第二业务逻辑生成下游任务。

可选地，作为一个实施例，所述任务调度装置1000，还可以包括：

检测模块，用于若所述上游任务在所述时间范围内执行成功的实例个数小于所述依赖信息中配置的实例个数，则确定所述上游任务处于依赖检测不通过状态，等待下一次检测，直至确定所述上游任务处于依赖检测通过状态，执行所述下游任务。

可选地，作为一个实施例，通过预设时间表达式配置所述依赖信息中的时间范围。

本申请实施例中的任务调度装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personaldigital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(NetworkAttached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的任务调度装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为iOS操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的任务调度装置能够实现图1方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图11所示，本申请实施例还提供一种电子设备1100，包括处理器1101，存储器1102，存储在存储器1102上并可在所述处理器1101上运行的程序或指令，该程序或指令被处理器1101执行时实现上述任务调度方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图12为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备1200包括但不限于：射频单元1201、网络模块1202、音频输出单元1203、输入单元1204、传感器1205、显示单元1206、用户输入单元1207、接口单元1208、存储器1209、以及处理器1210等部件。

本领域技术人员可以理解，电子设备1200还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1210逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图12中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

其中，处理器1210，用于获取上游任务和下游任务，其中，所述下游任务的执行依赖于所述上游任务；配置所述下游任务的依赖信息，其中，所述依赖信息中包含所述上游任务的标识、依赖所述上游任务的时间范围和依赖所述上游任务的实例个数；根据所述依赖信息，确定所述上游任务的执行情况；根据所述执行情况，确定所述上游任务在所述时间范围内执行成功的实例个数是否不小于所述依赖信息中配置的实例个数；若是，则确定所述上游任务处于依赖检测通过状态，执行所述下游任务。

可见，本申请实施例中，在获取上游任务和下游任务之后，配置下游任务的依赖信息，其中，依赖信息中包含上游任务的标识、依赖上游任务的时间范围和依赖上游任务的实例个数；根据依赖信息，确定上游任务的执行情况；根据执行情况，确定上游任务在上述时间范围内执行成功的实例个数是否不小于依赖信息中配置的实例个数，若是，则确定上游任务处于依赖检测通过状态，执行下游任务。与现有技术相比，本申请实施例中，在配置下游任务的依赖策略时，通过在依赖策略中加入依赖上游任务的时间范围参数，来建立上游任务与下游任务的依赖关系，基于所配置的依赖策略进行任务依赖检测，可以支持各种类型的业务场景，灵活性较高。

可选地，作为一个实施例，显示单元1206，用于显示依赖信息配置页面，其中，所述依赖信息配置页面上显示以下三个设置项目：依赖任务标识设置项、依赖时间范围设置项和依赖实例个数设置项；

用户输入单元1207，用于接收用户在所述三个设置项目中输入的信息；

处理器1210，还用于将用户输入的信息设置为所述下游任务的依赖信息。

可选地，作为一个实施例，处理器1210，还用于获取第一业务逻辑和第二业务逻辑；根据所述第一业务逻辑生成上游任务，以及根据所述第二业务逻辑生成下游任务。

可选地，作为一个实施例，处理器1210，还用于若所述上游任务在所述时间范围内执行成功的实例个数小于所述依赖信息中配置的实例个数，则确定所述上游任务处于依赖检测不通过状态，等待下一次检测，直至确定所述上游任务处于依赖检测通过状态，执行所述下游任务。

可选地，作为一个实施例，通过预设时间表达式配置所述依赖信息中的时间范围。

应理解的是，本申请实施例中，输入单元1204可以包括图形处理器(GraphicsProcessing Unit，GPU)12041和麦克风12042，图形处理器12041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元1206可包括显示面板12061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板12061。用户输入单元1207包括触控面板12071以及其他输入设备12072。触控面板12071，也称为触摸屏。触控面板12071可包括触摸检测装置和触摸控制器两个部分。其他输入设备12072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。存储器1209可用于存储软件程序以及各种数据，包括但不限于应用程序和操作系统。处理器1210可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1210中。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述任务调度方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述任务调度方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。