CN116882716B - 任务调度方法、设备及存储介质 - Google Patents

Abstract

本发明涉及任务调度技术领域，公开了一种任务调度方法、设备及存储介质。任务调度方法包括：定时检测各工作流是否符合各自对应的任务触发条件，工作流的触发方式包括时间触发或依赖触发；若存在符合任务触发条件的工作流，则将工作流放入待执行队列中等待执行；当工作流执行完成时，查询预置依赖配置表中工作流是否存在跨工作流或跨目录的下游依赖任务；若工作流存在下游依赖任务，则生成工作流的完成通知记录并写入预置完成通知表中以供触发下游依赖任务。本发明实现了跨工作流跨目录的任务依赖调度，逻辑关系清晰、可读性高，同时便于运维管理，保证了任务依赖调度的可靠性。

Description

任务调度方法、设备及存储介质

技术领域

本发明涉及任务调度技术领域，尤其涉及一种任务调度方法、设备及存储介质。

背景技术

现有业务***的任务调度一般都是由不同团队协作，各团队分别创建各自用于任务调度的目录和工作流，然后按照设定顺序进行任务调度。例如，在某个业务调度场景中，先触发原始表采集数据，原始表采集数据完成后再触发下游各自的分析脚本，分析脚本的分析结果入库后再触发一些推送任务，进而实现一连串的任务调度。现有任务调度场景中，任务依赖关系只有属于同一个工作流的任务之间才有，跨工作流和跨目录的任务之间无法进行上下依赖，如果业务比较复杂，也即所有任务必须要在一个工作流中实现，则会导致逻辑关系混乱且可读性差、无法管理，而分开到不同工作流中又无法预估有上下游逻辑关系的各个节点的工作流完成的时间，进而无法保证任务触发的可靠性。

发明内容

本发明的主要目的在于，提供一种任务调度方法、设备及存储介质，旨在解决现有任务依赖调度不能跨工作流和跨目录实现任务依赖调度，进而导致各任务之间逻辑关系混乱，难以管理的技术问题。

本发明第一方面提供了一种任务调度方法，所述任务调度方法包括：

定时检测各工作流是否符合各自对应的任务触发条件，所述工作流的触发方式包括时间触发或依赖触发；

若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行；

当所述工作流执行完成时，查询预置依赖配置表中所述工作流是否存在跨工作流或跨目录的下游依赖任务；

若所述工作流存在下游依赖任务，则生成所述工作流的完成通知记录并写入预置完成通知表中以供触发下游依赖任务。

可选的，在本发明第一方面的第一种实现方式中，所述定时检测各工作流是否符合各自对应的任务触发条件包括：

当所述工作流采用时间触发时，定时检测所述工作流的下一次触发时间是否小于当前时间；

若所述工作流的下一次触发时间小于当前时间，则确定所述工作流符合所述任务触发条件；

若所述工作流的下一次触发时间大于或等于当前时间，则确定所述工作流不符合所述任务触发条件并等待下一次定时检测。

可选的，在本发明第一方面的第二种实现方式中，所述若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行包括：

若所述工作流采用时间触发且符合所述任务触发条件，则将所述工作流放入待执行队列中等待执行，并更新所述工作流的下一次触发时间。

可选的，在本发明第一方面的第三种实现方式中，所述定时检测各工作流是否符合各自对应的任务触发条件还包括：

当所述工作流采用依赖触发时，定时检测所述完成通知表中是否存在所述工作流的所有上游依赖任务的完成通知记录；

若所述完成通知表中存在所述工作流的所有上游依赖任务的完成通知记录，则确定所述工作流符合所述任务触发条件；

若所述完成通知表中存在所述工作流的部分上游依赖任务的完成通知记录，则等待下一次定时检测。

可选的，在本发明第一方面的第四种实现方式中，所述若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行还包括：

若所述工作流采用依赖触发且符合所述任务触发条件，则将所述工作流放入待执行队列中等待执行；

根据所述工作流与各上游依赖任务之间依赖频率，对所述工作流的上游依赖任务写入所述完成通知表中的完成通知记录进行删除处理。

可选的，在本发明第一方面的第五种实现方式中，所述根据所述工作流与各上游依赖任务之间依赖频率，对所述工作流的上游依赖任务写入所述完成通知表中的完成通知记录进行删除处理包括：

若所述工作流存在多个跨工作流或跨目录的上游依赖任务，则分别判断所述工作流与各上游依赖任务之间依赖频率是否相同；

若所述工作流与各上游依赖任务之间依赖频率相同，且所述工作流与各上游依赖任务属于同一批次，则删除所述完成通知表中所述工作流的所有上游依赖任务的同一批次完成通知记录。

可选的，在本发明第一方面的第六种实现方式中，所述若所述工作流存在多个跨工作流或跨目录的上游依赖任务，则分别判断所述工作流与各上游依赖任务之间依赖频率是否相同之后，还包括：

若所述工作流与各上游依赖任务之间依赖频率不相同，且所述工作流与各上游依赖任务属于同一批次，则删除所述完成通知表中所述工作流与上游依赖任务之间依赖频率为多次的同一批次完成通知记录，保留所述完成通知表中所述工作流与上游依赖任务之间依赖频率为一次的同一批次完成通知记录，直至满足无效记录清理条件时进行删除。

可选的，在本发明第一方面的第七种实现方式中，所述任务调度方法还包括：

获取前端根据业务编排的跨工作流或跨目录的任务依赖关系；

根据所述任务依赖关系，在所述依赖配置表中添加对应配置信息，其中，所述配置信息包括上游任务标识、下游任务标识以及下游任务依赖上游任务的依赖频率。

本发明第二方面提供了一种计算机设备，所述计算机设备包括：存储器和至少一个处理器，所述存储器中存储有指令；所述至少一个处理器调用所述存储器中的所述指令，以使得所述计算机设备执行如上述任一项所述的任务调度方法。

本发明第二方面提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，所述指令被处理器执行时实现如上述任一项所述的任务调度方法。

本发明提供的技术方案中，定时检测各工作流是否符合各自对应的任务触发条件，若存在符合任务触发条件的工作流，则将该工作流放入待执行队列中等待执行。本发明的工作流触发方式包括时间触发或依赖触发，不同触发方式对应的触发条件不同。当工作流执行完成时，先查询依赖配置表中该工作流是否存在跨工作流或跨目录的下游依赖任务，若该工作流存在下游依赖任务，则生成工作流的完成通知记录并写入完成通知表中，该完成通知记录用于触发下游依赖任务的执行。本发明通过依赖配置表建立其跨工作流或跨目录的不同任务之间的依赖关系，允许任务跨目录跨流依赖相应的一个或多个任务，同时通过完成通知表记录上游一个或多个任务的完成标志来进行批次识别以及触发下游任务的执行。本发明实现了跨工作流跨目录的任务依赖调度，逻辑关系清晰、可读性高，同时便于运维管理，保证了任务依赖调度的可靠性。

附图说明

图1为本发明实施例中任务调度方法的一个实施例示意图；

图2为本发明实施例中基于业务编排生成的跨工作流或跨目录的任务依赖关系示意图；

图3为本发明实施例中基于时间触发的任务调度过程示意图；

图4为本发明实施例中基于依赖触发的任务调度过程示意图；

图5为本发明实施例中频次相同的多任务依赖调度过程示意图；

图6为本发明实施例中频次不相同的多任务依赖调度过程的第一实施例示意图；

图7为本发明实施例中频次不相同的多任务依赖调度过程的第二实施例示意图；

图8为本发明实施例中频次不相同的多任务依赖调度过程的第三实施例示意图；

图9为本发明实施例中计算机设备的一个实施例示意图。

具体实施方式

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等（如果存在）是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”或“具有”及其任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为便于理解，下面对本发明实施例涉及的相关概念进行简要说明。本发明实施例中，任务调度模型分为三层：从大到小依次为目录、工作流、任务，具体说明如下：

任务（Job）：指具体任务，比如某个Job用于调用一个SQL分析脚本；

工作流（Flow）：由一个或多个任务Job组成，多个Job可以按照DAG有向无环图的方式组成一个Flow，本发明的任务调度具体指对不同工作流之间的调度。

目录（Catalog）：由一个或多个工作流Flow组成，一个目录下可以创建一个或多个工作流Flow。

待执行队列（Queue）：用于存放待执行的工作流，所有被触发执行的工作流首先放入待执行队列中，当资源池有资源时则启动进程处理待执行队列中的工作流。

工作流调度模式：现有的工作流调度模式默认只有时间调度模式，工作流基于时间点触发执行，本发明新增的依赖调度模式默认不依赖于时间执行，而是由上游的其他目录或工作流中的任务依赖触发，可以选择多个任务进行依赖；

依赖配置表：区别于工作流内部的DAG依赖关系，依赖配置表中记录的是跨工作流或者跨目录的任务依赖关系；

完成通知表：每一个上游任务在执行完成之后，根据依赖配置表中的信息，形成完成通知记录，以向其所有下游发送任务完成的通知；

完成批次：每一个任务在执行的时候有一个唯一的默认批次，这里默认是按照自然日处理，比如批次20230511，也可以根据需要配置业务日历作为完成批次，比如银行和证券交易的交易日期等，任务可以重跑或者重试某一个或者多个批次的执行，并且执行完成后会重新发送完成通知，批次的初始化由待调度任务对应的最上游的时间触发的工作流生成，其触发的下游全部沿用这个批次；

多任务依赖的依赖频率：因为依赖的上游任务可能执行频率不同，比如任务A可能一天执行一次，而任务B一小时执行一次，如果想要在任务A和B都触发后才执行当前工作流，并且此后B每触发一次当前任务就要重复执行一次，那么在给当前工作流配置依赖关系时，其依赖任务A的依赖频率设置为一次，而其依赖任务B的频率设置为多次。

为便于理解，下面对本发明实施例的具体流程进行描述，请参阅图1，本发明实施例中任务调度方法的一个实施例包括：

101、定时检测各工作流是否符合各自对应的任务触发条件，工作流的触发方式包括时间触发或依赖触发；

102、若存在符合任务触发条件的工作流，则将工作流放入待执行队列中等待执行；

本实施例中，业务***运行过程中需要调度的任务很多，针对每一个工作流都需要判断其当前是否符合其自身对应的任务触发条件，如果符合，则将工作流放入待执行队列中等待执行，当资源池有资源时则启动进程处理待执行队列中的工作流。

本实施例采用定时检测的方式，分别判断各工作流是否符合各自对应的任务触发条件。例如，每隔1分钟循环扫描每一个工作流。

本实施例中，工作流的触发方式包括时间触发或依赖触发，不同触发方式的调度逻辑不同。

（1）任务触发条件：时间触发，触发方式与时间有关。

在一实施例中，上述步骤101具体包括：当工作流采用时间触发时，定时检测工作流的下一次触发时间是否小于当前时间；若工作流的下一次触发时间小于当前时间，则确定工作流符合任务触发条件；若工作流的下一次触发时间大于或等于当前时间，则确定工作流不符合任务触发条件并等待下一次定时检测。

在一实施例中，上述步骤102具体包括：若工作流采用时间触发且符合任务触发条件，则将工作流放入待执行队列中等待执行，并更新工作流的下一次触发时间。

例如，工作流A按照时间触发，其配置的时间触发条件为整点触发。假设触发条件配置好的瞬间时间点为8:50并保存配置，则该工作流A的下一次执行时间就是9:00，假设当前时间为9:01，定时扫描程序扫描全部工作流后发现工作流A的下一次执行时间（9:00）小于当前时间（9:01），因此将该工作流A放到待执行队列中，并且修改工作流A的下一次执行时间为10:00； 定时扫描程序持续按照间隔一分钟执行一次的频率扫描各工作流，如不9:02扫描一次，9:03扫描一次...；之后在10:01 扫描时，定时扫描程序会再一次发现工作流A，并将其再次放到待执行队列中，后续再进行无限循环执行或者在满足设定的条件后结束扫描。

（2）任务触发条件：依赖触发，触发方式与上游工作流中任务有关。其中，依赖的工作流为下游依赖任务，被依赖的工作流中的任务为上游依赖任务。一个下游依赖任务可以依赖多个上游依赖任务，不同下游依赖任务可以依赖同一个上游依赖任务。

在一实施例中，上述步骤101具体包括：当工作流采用依赖触发时，定时检测完成通知表中是否存在工作流的所有上游依赖任务的完成通知记录；若完成通知表中存在工作流的所有上游依赖任务的完成通知记录，则确定工作流符合任务触发条件；若完成通知表中存在工作流的部分上游依赖任务的完成通知记录，则等待下一次定时检测。

在一实施例中，上述步骤102具体包括：若工作流采用依赖触发且符合任务触发条件，则将工作流放入待执行队列中等待执行；根据工作流与各上游依赖任务之间依赖频率，对工作流的上游依赖任务写入完成通知表中的完成通知记录进行删除处理。

103、当工作流执行完成时，查询预置依赖配置表中工作流是否存在跨工作流或跨目录的下游依赖任务；

104、若工作流存在下游依赖任务，则生成工作流的完成通知记录并写入预置完成通知表中以供触发下游依赖任务。

本实施例中，依赖配置表用于记录跨工作流或者跨目录的任务依赖关系，当任意工作流执行完成时，都会先查询依赖配置表中该工作流是否存在跨工作流或跨目录的下游依赖任务，如果该工作流存在下游依赖任务，则生成工作流的完成通知记录，并将完成通知记录写入完成通知表中以供用于判断是否触发下游依赖任务。

在一实施例中，采用以下方式生成依赖配置表中的各任务依赖关系：

获取前端根据业务编排的跨工作流或跨目录的任务依赖关系；

根据任务依赖关系，在依赖配置表中添加对应配置信息，其中，配置信息包括上游任务标识、下游任务标识以及下游任务依赖上游任务的依赖频率。

本实施例中，开发人员可以基于***提供的UI界面进行业务工作流编排，进而生成跨工作流或跨目录的任务依赖关系，该任务依赖关系包括各工作流之间的上下游关系、依赖频率。需要补充说明的是，由于工作流Flow一般由多个任务Job组成，各任务Job依次独立运行，因此，下游任务依赖上游任务具体为下游的工作流依赖上游工作流中的单个任务Job而形成任务依赖关系。

本实施例中，将整个业务的实现过程细分，进而将一个非常复杂的业务链路拆分成几个甚至十几个小的环节来独立控制，比如每一个环节对应一个任务Job，则单个工作流Flow或者单个任务Job可能需要重复循环执行多次。本实施例的上述步骤101-104对应为单个工作流的任务调度实现过程，引入了定时检测机制，通过定时检测各工作流的触发条件，进而实现上述步骤101-104重复循环执行。

本实施例中，定时检测各工作流是否符合各自对应的任务触发条件，若存在符合任务触发条件的工作流，则将该工作流放入待执行队列中等待执行。本发明的工作流触发方式包括时间触发或依赖触发，不同触发方式对应的触发条件不同。当工作流执行完成时，先查询依赖配置表中该工作流是否存在跨工作流或跨目录的下游依赖任务，若该工作流存在下游依赖任务，则生成工作流的完成通知记录并写入完成通知表中，该完成通知记录用于触发下游依赖任务的执行。本发明通过依赖配置表建立其跨工作流或跨目录的不同任务之间的依赖关系，允许任务跨目录跨流依赖相应的一个或多个任务，同时通过完成通知表记录上游一个或多个任务的完成标志来进行批次识别以及触发下游任务的执行。本发明实现了跨工作流跨目录的任务依赖调度，逻辑关系清晰、可读性高，同时便于运维管理，保证了任务依赖调度的可靠性。

现有任务调度的工作流触发方式仅支持时间触发以及位于同一工作流内的任务依赖触发，而本实施例不仅持工作流的时间触发，同时还支持跨工作流或跨目录的工作流依赖触发。此外，在现有任务调度场景中，工作流Flow中的任务Job只能按照编排的DAG有向无环图进行触发执行，因而不能灵活的处理依赖触发关系，比如单次触发、多次触发、依赖不同触发频次的任务。

为解决现有任务调度场景中不同触发频次的依赖调度问题，在本发明一实施例中，在调度执行下游依赖任务之前，根据工作流（也即下游依赖任务）与各上游依赖任务之间依赖频率，对工作流的上游依赖任务写入完成通知表中的完成通知记录进行删除处理。

（1）频次相同的多任务依赖

若工作流存在多个跨工作流或跨目录的上游依赖任务，则分别判断工作流与各上游依赖任务之间依赖频率是否相同；

若工作流与各上游依赖任务之间依赖频率相同，且工作流与各上游依赖任务属于同一批次，则删除完成通知表中工作流的所有上游依赖任务的同一批次完成通知记录。

（2）频次不相同的多任务依赖

若工作流与各上游依赖任务之间依赖频率不相同，且工作流与各上游依赖任务属于同一批次，则删除完成通知表中工作流与上游依赖任务之间依赖频率为多次的同一批次完成通知记录，保留完成通知表中工作流与上游依赖任务之间依赖频率为一次的同一批次完成通知记录，直至满足无效记录清理条件时进行删除。

为便于更好理解本发明基于依赖关系的任务调度方法，下面结合附图，对任务调度过程进行举例说明。

实施例1：任务依赖关系编排，图2为本发明实施例中基于业务编排生成的跨工作流或跨目录的任务依赖关系示意图。

用户通过UI界面进行业务编排，形成跨工作流或跨目录的任务依赖关系，用户在UI界面操作时每添加一个依赖关系，后台的依赖配置表就会添加对应的配置信息，其中，FlowA作为该编排业务的最上游工作流，其触发方式采用时间触发，下游的工作流FlowX、FlowY、FlowZ则都是依赖触发，具体依赖关系如图中所示。其中，FlowX依赖FlowA.Job4的频率是一次，FlowY依赖FlowX.Job1的频率是一次，FlowZ依赖FlowA.Job4的频率是多次（这里的多次可以是具体数值，比如3次、5次，也可以是非具体数值），其中，依赖频率为多次的需要多次重复执行。

实施例2：时间触发方式的任务调度，图3为本发明实施例中基于时间触发的任务调度过程示意图。

当进行定时检测时，每间隔1分钟执行后台的定时监测任务，检测到时间触发任务FlowA符合设定的时间触发条件：假设当前时间为2023-05-11 09:01:00，定时扫描程序扫描全部工作流后发现工作流FlowA的下一次执行时间（2023-05-11 09:00:00，如图2中所示）小于当前时间，因此将该工作流FlowA放到待执行队列中，并且更新工作流FlowA的下一次执行时间为2023-05-12 09:00:00（如图3中所示）。

当资源池有资源执行FlowA时，FlowA中的每一个任务Job执行完成，都会去依赖配置表中查询其是否有下游依赖，并结合当前批次20230511以及其下游任务ID一起写入记录到完成通知表，单个任务Job有多少个下游依赖就会生成多少条完成通知记录，比如FlowX和FlowZ都依赖FlowA.Job4，则FlowA.Job4执行完成时，对应生成FlowX和FlowZ的2条完成通知记录，具体如图3所示。

实施例3：依赖触发方式的任务调度，图4为本发明实施例中基于依赖触发的任务调度过程示意图。

依赖时间的工作流的触发入口是后台每1分钟循环的任务和时间监测，而依赖调度的工作流的触发入口则是后台每1分钟循环时检测完成通知表中的记录。如图4所示，FlowA.Job4执行完成时，对应生成FlowX和FlowZ的2条完成通知记录并写入完成通知表中，以供通知FlowZ和 FlowX其依赖的上游任务已完成，同时通过依赖配置表中的依赖关系，确定FlowZ和 FlowX 各自所有的上游任务都给其发送了通知，则将FlowZ和 FlowX放入待执行队列中，然后删除完成通知表中FlowZ和 FlowX对应的完成通知记录。

另外，当FlowX执行完成后，同样其生成对应的完成通知记录并写入完成通知表中，后台会继续通知其下游依赖的工作流FlowY，将FlowY放入待执行队列中等待执行，然后删除对应的完成通知记录（如图4中完成通知表中画横线的记录），如此循环，直到整个依赖链路的终点（最后一个工作流不存在下游依赖）。

实施例4：频次相同的多任务依赖，图5为本发明实施例中频次相同的多任务依赖调度过程示意图。

例如，FlowY依赖有多个上游任务，多任务依赖调度的逻辑基本上是一致的，只是要求FlowY的所有上游任务全部都记录了完成通知才可以触发，同时，在判断 FlowY所有上游任务时，还进一步判断一下其执行的批次是否相同，多任务依赖调度要求具有依赖关系的上下游任务必须是采用相同的执行批次，比如图5中的批次为20230511。

如图5所示，FlowY依赖了两个上游任务FlowX.job1和FlowB.job2，其各自完成后都发送完成通知给FlowY，1分钟定时检测中根据依赖配置表和完成通知表，即可判断当前FlowY符合触发条件，将FlowY放入待执行队列中并删除完成通知表中对应的两条完成通知记录。需要说明的是，频次相同的多任务依赖删除完成通知的逻辑如下：如果依赖的多个上游任务的依赖频率相同，比如都是一次或者多次，则工作流进入待执行队列之后，再删除所有依赖的上游任务的完成通知记录。

实施例5：频次相同的多任务依赖，图6-8为本发明实施例中频次不相同的多任务依赖调度过程示意图。

在某些特殊业务场景中，需要基于业务需要而配置不同的依赖频率，比如在计算资产时，持仓信息的任务采集和加工是日批的，即每日清算后进行一次采集，而标的价格每日会有多次采集加工，持仓与价格的乘积得出一个时效更高的资产结果，那么就需要在标的交割每次加工完成后重新计算一次资产。这就是一个典型的依赖上游多个任务的业务场景，需要采用执行频率不同的任务。

如图6所示，假如计算资产的工作流为FlowY，计算持仓的工作流为 FlowA，计算价格的任务为FlowB，那么只需要配置FlowY依赖FlowA的频率为一次（按照链路实际是FlowY依赖FlowX一次，所有依赖调度的任务 FlowX、FlowY、FlowZ都必须要有一个定时调度任务作为源头，这里源头就是FlowA、FlowB），而FlowY依赖FlowB频率为多次。只有当FlowA 和FlowB都完成时才会触发FlowY，而触发FlowY之后会马上删除FlowB刚才产生的完成通知记录，而保留FlowA产生的完成通知记录，一直到FlowB再一次完成后重新写入一条新的完成通知记录，下次后台一分钟扫描才会重新触发FlowY；到了第二天批次切换为20230512之后，依赖关系又会从新开始。

如图7所示，在时间到达2023-05-11 9点时，FlowA->FlowX和FlowB都执行完成，进而触发FlowY 执行，将FlowY放入待执行队列之后，删除FlowB.job2的完成通知，但是保留了FlowX.job1的完成通知。

如图8所示，在2023-05-11 10点时FlowB会再次触发并写入完成通知记录，此时FlowY上游的完成通知又全部完成了，FlowY则会重新被触发并放入待执行队列中，然后删除FlowB 在2023-05-11 10点写入的完成通知记录，如此循环。

现有任务调度技术并不支持跨工作流和跨目录的任务依赖，而任务调度只有实现跨工作流和跨目录才能把整个业务的工作细化，从而把一个非常复杂的业务链路拆分成几个甚至十几个小的环节来独立控制，提升业务开发和项目管理的效率。

多任务依赖以及不同发生频率的任务依赖一直是现有任务调度的一个难题，有很多技术难点要克服，比如批次如何对齐以及状态机的控制等等，如果可以解决这些难点问题，则可以在调度层面完成一些复杂的逻辑控制，而不用将这些逻辑下沉到业务代码中，进而可极大减轻业务开发的工作量，尤其是很多重复性的业务逻辑，可以把业务单元拆分的极小，提高脚本的复用性，降低开发成本。

本发明通过以下技术创新，解决了上述技术难点：一个是工作量批次的统一；另一个是多个上游任务触发下游任务的状态机控制。

（一）工作量批次的统一

既然多个上游的发生频率不同，则必须从逻辑层面强制约束其一个批次，最常见的就是日批调度常用的***日期，或者金融行业常用的交易日期来作为批次，当然这一个批次其实是可以灵活多变的，比如使用全局变量统一控制，这个全局变量可以根据业务需要使用一些SQL或者更复杂的脚本来生成，一样可以给每一个运行的工作流确认其唯一的批次。有了批次就像是有了一个窗口，把无限循环执行的多个上游任务约束到比如一天的这个批次的有限窗口中进行状态匹配。

对于批次的统一，以采用时间依赖的最上游工作流（比如图2-8中的FlowA、FlowB）通过一定的公式生成批次，依赖最上游工作流的所有下游工作流继承此批次，而且也可以使用这个批次作为业务变量来使用比如SQL中通过变量指定数据日期等。所有依赖触发的工作流在检查到各自依赖的同一个批次的上游任务触发后，会按照同一个批次调度该工作流。

比如，采用以下方式生成批次：

（1）配置参数

Lag = 12hours （Lag表示延后处理时间）

Calendar=自然日历/交易日历

（2）批次计算公式

情形1：Calendar=自然日历

如果当前时间 - 当天0点>= Lag，则批次=当天

如果当前时间 - 当天0点<Lag，则批次=昨天

情形2：Calendar=交易日历

当天为交易日

如果当前时间 - 当天0点>= Lag，则批次=当前交易日

如果当前时间 - 当天0点<Lag，则批次=上一个交易日

当天为非交易日

批次=当前交易日

上述批次生成算法中，上面的当前时间指的是任务调度执行的实际时间， 当前交易日，比如今天是周五交易所开市那就是当前交易日，如果今天周六那当前交易日就是周五，节假日是一样的逻辑。

（二）状态机的工作逻辑

任务依赖调度需要根据上游的完成状态来输出控制信号，进而触发下游任务执行。本发明实施例中采用的状态机控制逻辑如下：

对一次依赖和多次依赖的状态实行区别处理，具体为：一次依赖的上游任务在触发后不清除状态（完成通知记录），多次依赖的上游任务在触发后清除状态（完成通知记录），以这样的方式来保证首先只有上游任务都完成才会第一次触发，其次是多次依赖的任务后续能够不断地触发下游的工作流。另外，也可以把每一个上游任务完成的状态扩展为一个复杂的表达式，比如一个复杂的多元方程来处理，引入一些外部的其他变量比如时间等，这样就可以适配一些非常复杂的调度逻辑。

多个上游任务触发下游任务的状态机控制采用区分一次依赖和多次依赖的方式实现，一次依赖的状态在触发下游后不清除，多次依赖的状态在触发下游后会清除，从而实现让多次依赖的上游能够多次触发下游工作流执行。

图9是本发明实施例提供的一种计算机设备的结构示意图，该计算机设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器（centralprocessing units，CPU）510（例如，一个或一个以上处理器）和存储器520，一个或一个以上存储应用程序533或数据532的存储介质530（例如一个或一个以上海量存储设备）。其中，存储器520和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块（图示没标出），每个模块可以包括对计算机设备500中的一系列指令操作。更进一步地，处理器510可以设置为与存储介质530通信，在计算机设备500上执行存储介质530中的一系列指令操作。

计算机设备500还可以包括一个或一个以上电源540，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口560，和/或，一个或一个以上操作***531，例如Windows Serve，Mac OS X，Unix，Linux，FreeBSD等等。本领域技术人员可以理解，图9示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明还提供一种计算机设备，所述计算机设备包括存储器和处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时，使得处理器执行上述各实施例中的所述任务调度方法的步骤。本发明还提供一种计算机可读存储介质，该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行所述任务调度方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read-only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (6)

1.一种跨工作流或跨目录的任务调度方法，其特征在于，所述任务调度方法包括：

定时检测各工作流是否符合各自对应的任务触发条件，所述工作流的触发方式包括时间触发或依赖触发，所述工作流包括一个或多个任务；

若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行；

当所述工作流执行完成时，查询预置依赖配置表中所述工作流是否存在跨工作流或跨目录的下游依赖任务，所述目录包括一个或多个工作流，所述依赖配置表用于记录跨工作流或跨目录的任务依赖关系，所述任务依赖关系包括各工作流之间的上下游关系及依赖频率，依赖的工作流为下游依赖任务，被依赖的工作流中的任务为上游依赖任务；

若所述工作流存在下游依赖任务，则根据所述依赖配置表中的信息，生成所述工作流的完成通知记录并写入预置完成通知表中以供触发下游依赖任务；

其中，所述定时检测各工作流是否符合各自对应的任务触发条件包括：

当所述工作流采用依赖触发时，定时检测所述完成通知表中是否存在所述工作流的所有上游依赖任务的完成通知记录；若所述完成通知表中存在所述工作流的所有上游依赖任务的完成通知记录，则确定所述工作流符合所述任务触发条件；若所述完成通知表中存在所述工作流的部分上游依赖任务的完成通知记录，则等待下一次定时检测；

其中，所述若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行包括：

若所述工作流采用依赖触发且符合所述任务触发条件，则将所述工作流放入待执行队列中等待执行；若所述工作流存在多个跨工作流或跨目录的上游依赖任务，则分别判断所述工作流与各上游依赖任务之间依赖频率是否相同；若所述工作流与各上游依赖任务之间依赖频率相同，且所述工作流与各上游依赖任务属于同一批次，则删除所述完成通知表中所述工作流的所有上游依赖任务的同一批次完成通知记录；若所述工作流与各上游依赖任务之间依赖频率不相同，且所述工作流与各上游依赖任务属于同一批次，则删除所述完成通知表中所述工作流与上游依赖任务之间依赖频率为多次的同一批次完成通知记录，保留所述完成通知表中所述工作流与上游依赖任务之间依赖频率为一次的同一批次完成通知记录，直至满足无效记录清理条件时进行删除。

2.根据权利要求1所述的跨工作流或跨目录的任务调度方法，其特征在于，所述定时检测各工作流是否符合各自对应的任务触发条件包括：

当所述工作流采用时间触发时，定时检测所述工作流的下一次触发时间是否小于当前时间；

若所述工作流的下一次触发时间小于当前时间，则确定所述工作流符合所述任务触发条件；

若所述工作流的下一次触发时间大于或等于当前时间，则确定所述工作流不符合所述任务触发条件并等待下一次定时检测。

3.根据权利要求2所述的任务调度方法，其特征在于，所述若存在符合所述任务触发条件的工作流，则将所述工作流放入待执行队列中等待执行包括：

若所述工作流采用时间触发且符合所述任务触发条件，则将所述工作流放入待执行队列中等待执行，并更新所述工作流的下一次触发时间。

4.根据权利要求1所述的跨工作流或跨目录的任务调度方法，其特征在于，所述任务调度方法还包括：

获取前端根据业务编排的跨工作流或跨目录的任务依赖关系；

根据所述任务依赖关系，在所述依赖配置表中添加对应配置信息，其中，所述配置信息包括上游任务标识、下游任务标识以及下游任务依赖上游任务的依赖频率。

5.一种计算机设备，其特征在于，所述计算机设备包括：存储器和至少一个处理器，所述存储器中存储有指令；

所述至少一个处理器调用所述存储器中的所述指令，以使得所述计算机设备执行如权利要求1-4中任一项所述的跨工作流或跨目录的任务调度方法。

6.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现如权利要求1-4中任一项所述的跨工作流或跨目录的任务调度方法。