CN110895487B - 分布式任务调度系统 - Google Patents

Abstract

本发明公开了一种分布式任务调度系统，包括：用于存储待执行任务的任务信息的数据库、多个任务调度模块以及多个任务执行模块；其中，任务调度模块，适于判断待下发给任务执行模块的任务调度消息是否属于预设类型的消息；若是，将该任务调度消息按照预设的一致性策略下发给任务执行模块；任务执行模块，适于根据接收到的任务调度消息执行对应的任务，并向任务调度模块返回任务响应消息；其中，所述预设类型的消息包括：消息产生过程中需要访问所述数据库中存储的任务信息的消息。通过该一致性策略能够防止多个任务调度模块同时访问数据库所导致的数据不一致问题，提升服务稳定性。

Description

分布式任务调度系统

技术领域

本发明涉及计算机技术领域，具体涉及一种分布式任务调度系统。

背景技术

目前，随着互联网的高速发展，需要借助网络运行的任务种类日益繁多。在传统的任务运行方式中，大多由单一的一台机器负责运行多个任务，且各个任务的计算过程也需要由该台机器完成。

由此可见，在现有技术的任务运行方式中，能够同时运行的任务数量受限于该台机器的系统容量，无法同时并发大量的任务。并且，由于各个任务的计算过程也需要由该台机器完成，因此，对机器本身造成了巨大的负担，尤其是在任务种类多种多样时，由一台机器负责完成各类任务的计算过程，势必会对该台机器的负荷带来极大挑战。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的分布式任务调度系统。

根据本发明的一个方面，提供了一种分布式任务调度系统，包括：用于存储待执行任务的任务信息的数据库、多个任务调度模块以及多个任务执行模块；其中，任务调度模块，适于判断待下发给任务执行模块的任务调度消息是否属于预设类型的消息；若是，将该任务调度消息按照预设的一致性策略下发给任务执行模块；任务执行模块，适于根据接收到的任务调度消息执行对应的任务，并向任务调度模块返回任务响应消息；其中，所述预设类型的消息包括：消息产生过程中需要访问所述数据库中存储的任务信息的消息。

在本发明提供的分布式任务调度系统中，设置了用于存储待执行任务的任务信息的数据库、多个任务调度模块以及多个任务执行模块。其中，多个任务调度模块以及多个任务执行模块相互并行工作，提升了整个系统的并发量，解决了因单台机器资源不够所导致的性能瓶颈。并且，各个任务调度模块能够在判断出待下发给任务执行模块的任务调度消息属于预设类型的消息时，将该任务调度消息按照预设的一致性策略下发给任务执行模块。其中，预设类型的消息包括消息产生过程中需要访问数据库中存储的任务信息的消息。由此可见，通过该一致性策略能够防止多个任务调度模块同时访问数据库所导致的数据不一致问题，提升服务稳定性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例一提供的一种分布式任务调度系统的结构示意图；

图2示出了本发明实施例二提供的一种任务恢复方法的流程示意图；

图3示出了本发明实施例三提供的一种任务调度方法的流程示意图；

图4示出了本发明实施例四提供的一种任务调度方法的流程示意图；

图5示出了本发明实施例五提供的一种分布式任务调度系统的结构示意图；

图6示出了本发明实施例六提供的一种任务调度系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一、

图1示出了本发明实施例一提供的一种分布式任务调度系统的结构示意图。其中，分布式任务调度系统包括：前端交互模块11、任务调度模块12、多个分布式的任务执行模块13(图中仅示出了一个)、以及计算引擎模块14；其中，前端交互模块11，用于根据接收到的与任务相关的任务交互操作，向任务调度模块12发送任务交互请求，并接收任务调度模块12返回的任务交互结果；任务调度模块12，用于根据所述前端交互模块11发送的任务交互请求，确定各个待执行任务，并将各个待执行任务分发给所述任务执行模块13；任务执行模块13，用于执行所述任务调度模块分发的任务，并向所述任务调度模块返回任务执行结果；计算引擎模块14，用于供所述任务执行模块13进行调用，以实现任务执行过程中的计算处理。

其中，前端交互模块，也叫用户接口模块(即UI模块)，用于提供访问数据库、提供任务、kill任务等操作。任务调度模块12的数量可以为多个，各个任务调度模块主要用于对任务进行调度，提供日志、任务恢复、采集机器监控信息、调度资源发送等功能。任务执行模块负责接收并执行任务、更新任务状态、拓扑功能等服务。计算引擎模块包括多个与任务执行模块解耦的子模块，以供各个任务执行模块根据待执行任务的任务类型调用对应的子模块。通过计算引擎模块14能够使整个系统中的其他模块和计算引擎解耦，使该系统不依赖于任何计算引擎，也方便计算引擎扩展。例如，多个与任务执行模块解耦的子模块可以包括：Spark子模块、MapReduce子模块、Flink子模块等。

由此可见，根据本发明提供的分布式任务调度系统，借助于任务调度模块的调度功能，能够通过多个分布式的任务执行模块并行地执行多个任务，从而大幅提升了任务的并发量。并且，借助于计算引擎模块，能够将复杂的任务计算过程从任务执行模块中剥离出来，从而有利于减轻任务执行模块的负荷，以便于任务执行模块运行更多的任务。

实施例二、

图2示出了本发明实施例二提供的一种任务恢复方法的流程示意图。优选地，该任务恢复方法应用于本发明实施例一中的分布式任务调度系统中。当然，本领域技术人员能够知晓的是，该任务恢复方法也可以应用于其他形式的系统或设备中，本发明不限定该任务恢复方法的应用场景。

为了便于理解，以该任务恢复方法应用于实施例一中的分布式任务调度系统为例进行说明。如图2所示，该任务恢复方法包括以下步骤：

步骤S210：针对启动成功的任务创建与该任务相对应的元数据文件，并在该任务的运行过程中，通过与该任务相对应的元数据文件记录该任务的任务相关信息。

本步骤及其后续步骤的执行主体可以为图1中的任一任务执行模块。由于任务执行模块可能由于各种原因而暂停服务(例如系统升级期间调度服务会暂停)，在其暂停服务的期间，任务执行模块上正在执行的任务不必随之暂停，而是能够在后台继续执行。因此，为了在任务执行模块恢复服务之后，能够针对其暂停服务期间在后台运行的各个任务的状态进行更新，以使该任务执行模块中的各个任务能够不间断地运行，在本实施例中，针对每个待启动的任务，监测其启动状态是否为成功，若否，则清理重置；若是，则针对该启动成功的任务创建与该任务相对应的元数据文件，以便在该任务的运行过程中，通过与该任务相对应的元数据文件记录该任务的任务相关信息。

其中，元数据文件记录的任务相关信息包括以下中的至少一个：任务运行时间、任务所属系统、任务标识、任务运行时间戳、任务模板、运行任务的进程信息、错误状态码、模板校验码、日志偏移信息、日志回调接口；其中，任务运行时间戳用于去除重复任务，错误状态码用于确定任务的执行状态，日志偏移信息用于实现日志的断点续传。

由此可见，该元数据文件在任务启动成功时进行创建，并且，随着任务运行过程的持续进行，该元数据文件中记录的任务相关信息不断更新，以实时反映该任务的当前运行状态。

步骤S220：当预设的任务恢复条件满足时，查询与各个任务相对应的元数据文件。

其中，该预设的任务恢复条件可以为各类与暂停服务之后恢复服务相关的条件。例如，可以为系统升级后执行的重启操作、或系统故障恢复后执行的启动操作等。每当预设的任务恢复条件满足时，自动查询与各个任务相对应的元数据文件，以便执行任务恢复处理。

步骤S230：根据查询结果确定各个任务的执行状态，根据各个任务的执行状态对各个任务进行恢复处理。

具体地，在根据各个任务的执行状态对各个任务进行恢复处理时，可以对已经运行完成的任务的状态进行更新，还能够将仍在运行的任务接管，使得在调度系统的管理下继续运行，直到该任务结束。例如，在调度系统中可维护一个任务状态表，该任务状态表既可以存储在对应的任务执行模块中，也可以存储在任务调度模块中，该任务状态表用于记录各个任务的运行状态，相应地，在根据各个任务的执行状态对各个任务进行恢复处理时，若该任务已执行完毕，则在任务状态表中将其状态修改为已结束状态，并根据任务执行结果，如成功或失败进行记录；若该任务未执行完毕，则根据元数据文件确定该任务当前的运行状态，根据该当前的运行状态更新任务状态表中的状态，并接管该任务，使其在调度系统的管理下继续运行。当其在调度系统的管理下运行时，将根据运行状态的变化实时更新任务状态表。

另外，可选地，在根据各个任务的执行状态对各个任务进行恢复处理之后，进一步针对运行结束的任务，生成用于指示该任务的运行状态的状态结果，并删除与该任务相对应的元数据文件，以降低资源占用。由此可见，本实施例能够提供用户无感知的系统升级操作，在调度系统升级之后，任务不必重新运行，节省了计算资源。

具体实施时，本发明提供了本地任务恢复方式以及云端任务恢复方式。下面通过两个示例分别介绍两种恢复方式：

示例一、

本地任务恢复方式主要用于在各个任务执行模块的本地进行任务恢复，各个任务执行模块负责本模块内部的各个任务的恢复操作，该方式具有传输速度快、操作便捷等诸多优势。

具体地，当采用本地任务恢复方式时，步骤S210具体为：针对启动成功的任务创建与该任务相对应的元数据文件时，在用于运行启动成功的任务的任务执行模块的本地存储空间内创建与该任务相对应的元数据文件。也就是说，各个任务执行模块针对本模块内的任务，在本模块的本地存储空间内创建与该任务相对应的元数据文件，该元数据文件通常仅能够被本模块访问，其他任务执行模块在未经授权的情况下无法访问。

相应地，步骤S220具体为：用于运行启动成功的任务的任务执行模块在预设的任务恢复条件满足时，查询该任务执行模块的本地存储空间内存储的与各个任务相对应的元数据文件。例如，当一个任务执行模块升级后重启时，查询该任务执行模块的本地存储空间内存储的与各个任务相对应的元数据文件，并根据查询结果确定各个任务的执行状态，根据各个任务的执行状态对各个任务进行恢复处理。该方式能够有效恢复各个任务执行模块本地的任务。

由此可见，在本地任务恢复方式中，当任务启动成功后，会创建一个元数据文件，格式如：thedate_sysId_taskId_timestamp_tempId_pid_startTime，并写入内容：{"errCode":-1,"checksum":"","lastOffset":0,"callback":{"report_log_url":"xxx","sys_token":"xxxxx"}}。其中，元数据文件名字段说明如下：thedate：任务运行时间；sysId：任务所属系统；taskId：任务Id；timestamp：任务运行时间戳，主要用于任务冗余汇报过滤；tempId：任务运行使用的模板；pid：运行任务的进程号；startTime：进程的启动时间。元数据文件内容字段说明如下：errCode：任务运行的错误码，0表示成功；checksum：任务运行使用的模板的校验码；lastOffset：上一次请求到的日志的行偏移量；callback：返回日志的接口；report_log_url:日志接口url；sys_token:日志接口验证码。在任务运行过程中，如果要实时回传任务运行的日志的话，利用callback中的接口进行日志回传，并不断的更新lastOffset的值，用于确定下次请求日志的起点位置。任务运行过程中，如果重启任务执行模块，则任务执行模块会利用元数据文件来重新加载这些需要恢复的任务。如果在任务执行模块还未启动时，任务已经运行结束，则该任务会将errCode写入到元数据文件中，等待任务执行模块启动后获取该值，做出相应的恢复动作。任务运行结束后，恢复的任务会根据元数据文件中的errCode的值，返回任务运行的状态，并删除相关元数据。其中，Report_log_url、lastOffset和sys_token用于解决任务日志断点续传的功能，当调度重新启动后，日志回传模块，会把lastOffset以后的日志发送到Report_log_url，并提供sys_token验证机制，让Report_log_url认为是合法的请求。

示例二、

云端任务恢复方式主要用于在某个任务执行模块异常时，由其他任务执行模块利用云端的元数据文件对该异常任务执行模块上的任务进行恢复。具体地，当采用云端任务恢复方式时，任务调度系统中通常包含多个任务执行模块，步骤S210具体为：针对启动成功的任务创建与该任务相对应的元数据文件时，在能够被多个任务执行模块共享的云存储空间内创建与该任务相对应的元数据文件。也就是说，各个任务执行模块将元数据文件创建在云存储空间中，该元数据文件不仅能够被本模块访问，还能够被其他任务执行模块访问。

相应地，步骤S220具体为：当预设的任务恢复条件满足时，在云存储空间查询与各个任务相对应的元数据文件。具体地，又分为两种查询方式，第一种查询方式为：由任务执行模块查询本模块上的任务所对应的元数据文件，以便恢复本模块上的各个任务。例如，当一个任务执行模块宕机后不能立即恢复时，该任务执行模块上的调度服务需要等待该模块重新启动后才能提供，为了避免该模块宕机时影响元数据文件的正常存储，可通过访问云存储空间的元数据文件的方式提升元数据文件的安全性，以避免存储在本地的元数据文件受到宕机影响。

第二种查询方式为：当某任务执行模块宕机后，由另一任务执行模块负责恢复宕机的模块上的任务。相应地，将满足预设的任务恢复条件的任务执行模块确定为第一执行模块，将满足预设异常条件的任务执行模块确定为第二执行模块；第一执行模块在预设的任务恢复条件满足时查询云存储空间内存储的与第一执行模块以及第二执行模块相对应的各个任务的元数据文件。例如，假设任务执行模块一在系统升级期间宕机超过预设时长，则确定任务执行模块一满足预设异常条件，为第二执行模块。假设任务执行模块二在系统升级后正常重启，则确定任务执行模块二满足任务恢复条件，为第一执行模块。相应地，当第一执行模块重启成功后，查询云存储空间内存储的与第一执行模块以及第二执行模块相对应的各个任务的元数据文件，以便对第一执行模块以及第二执行模块相对应的各个任务进行恢复。该方式相当于在某个任务执行模块故障后由其他任务执行模块负责接管并恢复其上的任务，从而提升了系统的鲁棒性。

其中，云存储空间可通过zookeeper(ZK)实现。由此可见，云端任务恢复方式只能应用于yarn-cluster的任务，而且无法回传日志，日志都存在集群上。当任务启动成功后，会向zkhedate_sysId_taskId_timestamp目录下写入元数据：{"errCode":-1,"checksum":"",“driver:“xxxxx”}。其中，元数据文件名字段说明如下：thedate：任务运行时间；sysId：任务所属系统；taskId：任务Id；timestamp：任务运行时间戳，主要用于任务冗余汇报过滤。元数据文件内容字段说明：errCode：任务运行的错误码，0表示成功；checksum：任务运行使用的模板的校验码；driver:存储yarn ResourceManager返回的地址(需要对yarn进行修改，支持该功能)。当任务运行过程中，如果任务执行模块重启或者死机，则任务执行模块会利用zk上存储的元数据文件来重新加载这些需要恢复的任务。如果在任务执行模块还未启动时，任务已经运行结束，则该任务需要通过zk将errCode写入到元数据文件中，等待任务执行模块启动后获取该值，做出相应的恢复动作。当任务运行结束后，恢复的任务会根据元数据文件中的errCode的值，返回任务运行的状态，并删除相关元数据。另外，在本实施例中，当任务运行结束后，还可以进一步将任务状态上报给任务调度模块，以供任务调度模块进行记录。

本实施例提供的任务恢复方法尤其适用于实时任务的恢复处理。当然，该恢复方法也可以应用于对离线任务进行恢复处理，本发明对此不做限定。由此可见，本发明通过元数据文件记录任务的执行状态，以便根据各个任务的执行状态对各个任务进行恢复处理。采用该方式，在系统升级等特殊情况下，正在运行的任务无需中止，能够继续在后台运行，并在任务恢复条件满足时，自动根据元数据文件恢复原本在后台运行的任务，从而节约了计算资源，提升了任务运行效率。

实施例三、

图3示出了本发明实施例三提供的一种任务调度方法的流程示意图。优选地，该任务调度方法应用于本发明实施例一中的分布式任务调度系统中。当然，本领域技术人员能够知晓的是，该任务调度方法也可以应用于其他形式的系统或设备中，本发明不限定该任务调度方法的应用场景。

为了便于理解，以该任务调度方法应用于实施例一中的分布式任务调度系统为例进行说明。如图3所示，该任务调度方法包括以下步骤：

步骤S300：预先设置多个任务维度并定义各个任务维度之间的大小关系，任务维度用于描述任务执行的时间信息。

本步骤为一个可选的步骤。其中，多个任务维度包括以下中的至少一个：分钟维度、小时维度、天维度、周维度、以及月维度；并且，月维度小于周维度，周维度小于天维度，天维度小于小时维度，小时维度小于分钟维度。

例如，在本实施例中，能够支持分钟、小时、天、周、月和立即运行的任务，主要包括以下几种维度的任务：分钟任务：Fxx(例如F10表示每10分钟运行1次)。小时任务：包括每小时运行任务HHH以及跨小时运行任务Hxx(如：H01，表示跨一个小时执行)，最大支持跨99个小时。天任务：包括每天运行任务DDD以及跨天运行任务Dxx(如：D01，表示跨一个小时执行)，最大支持跨99天。周任务：包括Wxx，其中，进一步包括周一运行任务(W01)以及周末运行任务(W07)。月任务：月末运行任务MMM以及月中运行任务Mxx。立即执行任务：III。相应地，定义任务维度大小如下：跨小时运行任务Hxx>每小时运行任务HHH>跨天运行任务Dxx>每天运行任务DDD>周任务Wxx>月中运行任务Mxx>月末运行任务MMM。即：任务执行周期越短的任务，任务维度越大；反之，任务执行周期越长的任务，任务维度越小。

步骤S310：根据预设的任务拓扑表运行待执行任务中的非依赖任务；其中，任务拓扑表用于存储待执行的各个任务之间的依赖关系。

在本实施例中，各个任务之间的依赖关系比较灵活，除了能够依赖相同维度的任务之外，还能够依赖不同维度的任务，因而便于创建符合各类实际需求的任务，适用场景更加宽泛。其中，任务拓扑表用于存储待执行的各个任务之间的依赖关系，通过该任务拓扑表，能够明确看出各个任务之间是否存在依赖关系。具体地，根据该任务拓扑表，将待执行任务中包含的不依赖于父任务的任务确定为非依赖任务(或者也可以将根任务确定为非依赖任务)；对非依赖任务进行初始化，并为非依赖任务申请对应的资源；将非依赖任务发送给多个任务执行模块中的一个任务执行模块，由该任务执行模块负责运行该非依赖任务。

另外，可选地，当非依赖任务为多个时，根据任务优先级确定各个非依赖任务之间的执行顺序，按照各个非依赖任务之间的执行顺序，依次运行各个非依赖任务；其中，各个任务的任务优先级根据预设的优先级设置规则设置。该优先级设置规则包括以下中的至少一个：动态检测各个任务的等待时长，根据等待时长调节对应任务的任务优先级；预先设置优先级数值的取值范围包括第一区间以及第二区间，第二区间大于第一区间，且第二区间对应于预设类型的任务。例如，在本发明中的任务调度系统中，任务优先级设计范围为【10–90】，常规任务的优先级范围为第一区间【10-80】，预设类型的任务，如系统任务或特殊任务的优先级为第二区间【80-90】。为了防止在大量任务需要运行时，优先级低的任务可能始终不能被运行的情况发生，本发明设计了任务优先级更新模块，用于检测各个任务的等待时长，并根据检测结果动态调整任务优先级：随着任务等待运行时间越来越长，该任务的优先级，会逐步增加到最大上限(例如优先级为80)。如果各个任务的优先级都达到最大上限时，将按照先进先出的方式选取任务，任务初始化时间越早，这个任务将会被优先运行。另外，为了使得一些紧急的任务尽早被运行(特别是系统升级，模型更新等任务)，本发明将预设类型的任务的优先级设置为最高(例如90)，但是常规任务的优先级通常不能设置为该值。

步骤S320：当非依赖任务运行成功时，根据任务拓扑表确定非依赖任务是否存在对应的子任务。

若非依赖任务对应的子任务为多个，则分别针对每个子任务执行后续的各个步骤。

步骤S330：若非依赖任务存在对应的子任务，根据任务拓扑表确定非依赖任务对应的子任务的父任务。

其中，任务之间的依赖包括隐式依赖以及显式依赖。隐式依赖是指：没有明确指定任务间的依赖关系，只是存在数据上的依赖，例如一个任务会依赖该任务昨天的输入，如果昨天的任务运行失败，该任务今天则不运行。显式依赖是指：明确制定了两个任务的依赖关系，存储了父任务和子任务的关系。本实施例主要针对于显式依赖情况。相应地，对于非依赖任务对应的子任务而言，可根据任务拓扑表确定该子任务的父任务。其中，该非依赖任务可以理解为该子任务的一个父任务，但是，很多情况下，一个子任务同时存在多个父任务，只有在所有父任务都运行成功后子任务才能运行，因此，本实施例主要需要找出非依赖任务对应的子任务的其他父任务。

步骤S340：判断非依赖任务对应的子任务的父任务是否已运行成功；若是，则运行非依赖任务对应的子任务。

其中，当非依赖任务对应的子任务的父任务为多个时，逐一判断该子任务的各个父任务是否已运行成功。具体实施时，确定子任务的任务维度以及父任务的任务维度，根据子任务的任务维度以及父任务的任务维度，判断非依赖任务对应的子任务的父任务是否已运行成功。在本实施例中，规定子任务的任务维度必须小于或等于父任务的任务维度，否则该依赖关系为非法。

当子任务的任务维度等于父任务的任务维度时，说明子任务与父任务的维度相同，此时，直接确定父任务本身是否已运行成功即可。当子任务的任务维度小于父任务的任务维度时，判断非依赖任务对应的子任务的父任务是否已运行成功时，需要进一步根据父任务的生命周期以及父任务的任务维度，计算父任务对应的理论运行次数；判断父任务的实际运行次数与理论运行次数是否匹配；若是，则确定父任务已运行成功。具体地，当子任务的任务维度小于父任务的任务维度时，例如子任务为每天执行的任务，父任务为每小时执行的任务，相应地，在子任务执行之前，需要确定父任务的理论运行次数，例如，假设父任务的生命周期为三天，任务维度为每小时执行，则在其生命周期内应执行的理论运行次数为3*24＝72。因此，需要判断父任务的实际运行次数是否为72次，若是，则确定父任务已运行成功。在本实施例中，通过定义父任务的生命周期能够约束父任务在系统中的存在时长，从而灵活满足各类只需短期执行的任务的需求。当然，也可以将任务的生命周期设置为无限长，从而使任务一直循环运行。

另外，可选地，该方法进一步包括：当接收到通过预设的拓扑暂停入口触发的拓扑暂停消息时，将拓扑状态设置为暂停状态；和/或，当接收到通过预设的拓扑恢复入口触发的拓扑恢复消息时，将拓扑状态从暂停状态恢复为激活状态。相应地，在步骤S320中，当非依赖任务运行成功时，根据任务拓扑表确定非依赖任务是否存在对应的子任务时，进一步查询拓扑状态是否为激活状态；若是，则根据任务拓扑表确定非依赖任务是否存在对应的子任务，并继续执行后续的步骤S330及其后续步骤；若否，则不执行根据任务拓扑表确定非依赖任务是否存在对应的子任务的操作，更不执行后续的步骤S330及其后续步骤。例如，在任务调试过程等特殊过程中，当非依赖任务运行成功时，不需要运行对应的子任务，此时可通过拓扑暂停功能避免子任务的自动执行，具体实施时，将任务的依赖状态字段置为0(非激活态)即可。在调试过程结束后，可使用拓扑恢复功能恢复子任务的自动执行，具体实施时，将任务的依赖状态字段置为2(激活态)即可。

总而言之，在本实施例中，在任务初始化时，只初始化根任务，其他的任务不进行初始化。当任务运行成功时，如果该任务激活依赖，则会检查该任务是否有子任务，如果有子任务，再逐一检查该子任务的父任务是否都运行成功，如果都运行成功，则初始化这个子任务，否则不处理。在判断一个子任务的父任务是否都运行成功时可以分为两种情况：子任务的计算维度与父任务的计算维度相同，则直接创建；子任务的计算维度小于父任务的计算维度，则要根据父任务的生命周期以及任务维度，计算父任务需要运行的次数和实际运行的次数，如果这两个数相同，则初始化子任务，否则不处理。

由此可见，该方式能够根据任务拓扑表先运行非依赖任务，并在非依赖任务运行成功时，自动查找非依赖任务对应的子任务，以及子任务的父任务，并自动判断非依赖任务对应的子任务的父任务是否已运行成功，若成功则自动运行非依赖任务对应的子任务。该方式无需用户人工判断各个任务之间的依赖关系，能够使存在依赖关系的任务在满足条件时自动运行，提升了效率，避免了误判。另外，本实施例不仅支持相同维度之间的任务相互依赖，还支持不同维度的任务之间相互依赖，因此，应用场景更灵活，可支持各种类型的任务。

另外，本实施例中的任务调度方法可由图1中的任务调度模块执行，以便实现整个系统内部的全体任务的合理调度。或者，也可由某一任务执行模块执行，以便实现该模块内的各个任务的合理的调度，本发明对此不做限定。

实施例四、

图4示出了本发明实施例四提供的一种任务调度方法的流程示意图。优选地，该任务调度方法应用于本发明实施例一中的分布式任务调度系统中。当然，本领域技术人员能够知晓的是，该任务调度方法也可以应用于其他形式的系统或设备中，本发明不限定该任务调度方法的应用场景。

为了便于理解，以该任务调度方法应用于实施例一中的分布式任务调度系统为例进行说明。如图4所示，该任务调度方法包括以下步骤：

步骤S410：将待执行任务分发给各个分布式的任务执行模块，并在数据库中记录各个任务执行模块对应的已分发任务。

本步骤可由任务调度模块执行，具体地，任务调度模块从数据库中读取待执行任务，并将读取到的各个待执行任务分发给各个分布式的任务执行模块。为了更加合理地分发任务，任务调度模块进一步监测各个任务执行模块的系统运行状态，根据监测结果向各个任务执行模块下发待执行任务。其中，系统运行状态包括以下中的至少一个：CPU状态、内存状态、磁盘使用率、任务并发数等。为了便于对已分发的任务进行维护，进一步在数据库中记录各个任务执行模块对应的已分发任务。具体记录时，需进一步记录任务执行模块以及已分发任务之间的对应关系，以便确定某任务具体由哪个任务执行模块运行。

步骤S420：接收各个任务执行模块每隔预设时间周期返回的任务状态列表，根据该任务状态列表中包含的模块标识信息确定发送该任务状态列表的任务执行模块。

各个任务执行模块每隔预设时间周期，整理本周期内的各个任务的状态，以便向任务调度模块返回用于反映该任务执行模块中的各个任务的执行状态的任务状态列表。相应地，任务调度模块接收到各个任务执行模块返回的任务状态列表后，根据该任务状态列表中包含的模块标识信息确定发送该任务状态列表的任务执行模块。其中，预设时间周期可由本领域技术人员灵活配置。

具体地，该任务状态列表中除包含任务执行模块的模块标识信息之外，还进一步包含该任务执行模块上的各个任务的任务标识以及该任务对应的状态信息。其中，状态信息可包括以下中的至少一个：初始化状态(I)、等待运行状态(W)、正在运行状态(R)、请求杀死任务(A)、正在杀死任务(B)、任务运行成功(S)、任务运行失败(F)、任务被杀死(K)。

步骤S430：从数据库中查询与发送该任务状态列表的任务执行模块对应的已分发任务。

由于在任务分发阶段记录了各个任务执行模块及其对应的已分发任务之间的对应关系，相应地，在本步骤中，根据任务状态列表中包含的模块标识信息确定出发送该任务状态列表的任务执行模块之后，进一步在数据库中查询与该任务执行模块相对应的已分发任务，以便确定分发给该任务执行模块的任务数量和类型。

步骤S440：将该任务状态列表与查询到的已分发任务进行比对，根据比对结果确定需要重发的任务，将需要重发的任务分发给至少一个任务执行模块。

具体地，将接收到的任务状态列表与查询到的对应的已分发任务进行比对。具体比对时，需要比对任务状态列表中的任务数量与查询到的对应的已分发任务的任务数量是否匹配。若该任务状态列表中包含的任务数量小于查询到的已分发任务，则进一步根据各个任务的任务标识确定遗漏任务，该遗漏任务为查询到的已分发任务中未包含在该任务状态列表中的任务，将该遗漏任务确定为需要重发的任务。

另外，为了防止因某些任务被执行了多次而导致查询到的任务数量不准确，在本实施例中，任务状态列表中的各个任务具有对应的时间戳信息，该时间戳信息用于描述该任务的初始化时间、运行时间和/或完成时间；相应地，在比对任务状态列表中的任务数量与查询到的对应的已分发任务的任务数量是否匹配时，先根据任务标识以及时间戳信息对任务进行去重处理：当对应于同一任务标识的任务为多个时，根据多个对应于同一任务标识的任务的时间戳信息，从多个对应于同一任务标识的任务中筛选一个任务作为有效任务；根据筛选后的有效任务统计该任务状态列表中包含的任务数量。该方式能够有效避免任务数量统计不准确的现象发生，而且也避免了同一任务被记录多次的错误情况。具体筛选时，可将时间戳信息最晚的任务或者运行状态为非异常状态的任务筛选为有效任务。

另外，由于任务状态列表中的各个任务具有对应的状态信息，该状态信息包括：初始化信息、运行信息、运行成功信息、运行失败信息、和/或最后更新时间信息等，相应地，在根据比对结果确定需要重发的任务时，还可以根据该任务状态列表中的各个任务的状态信息确定需要重发的任务。例如，可以将运行失败或因其他原因运行异常的任务进行重发。另外，将需要重发的任务分发给至少一个任务执行模块时，既可以分发给数据库中已记录的与该需要重发的任务相对应的任务执行模块，也可以根据各个任务执行模块的负载重新选择一个任务执行模块进行分发。

由此可见，在本实施例中，任务调度模块与各个任务执行模块之间可采用异步通信方式进行通信。相应地，任务调度模块向任务执行模块发送任务后，无需待其响应，该异步通信方式有助于提升系统运行效率。但是，发明人在实现本发明的过程中发现：该异步通信方式可能导致如下两方面问题：一方面，任务调度模块发送的任务可能没有被任务执行模块接收到(例如：网络异常或者任务执行模块重启等)，这种任务需要被重新发送到任务执行模块执行。另一方面，也存在任务调度模块没有收到任务执行模块反馈的消息的情况。为了解决上述问题，在本实施例中，由任务执行模块向任务调度模块发送过去一段时间内运行过的任务状态列表，任一任务调度模块根据任务状态列表判断任务是否丢失，或者判断是否接收消息失败。由此提升了系统的鲁棒性。

可选地，在根据该任务状态列表中的各个任务的状态信息确定需要重发的任务时，获取任务的状态信息中包含的最后更新时间；判断当前系统时间与最后更新时间之间的时间差是否大于预设宕机阈值；若是，则确定该任务为需要重发的任务；其中，为避免将升级过程误判为宕机，该预设宕机阈值大于系统升级时长。例如，机器(任务执行模块)宕机时，如果一些任务的状态为正在运行，且该任务的当前状态持续时间超过预设宕机阈值，如2小时(可由配置参数)没有更新。即：当前系统时间>＝最后更新时间+2小时，则认为该机器上的任务需要重新运行。为了防止因任务执行模块升级期间的状态没有更新的任务被误判为机器宕机，所以使预设宕机阈值大于系统升级时长。通过该种方式，任务调度模块可以有效检测到宕机的任务执行模块，并将该宕机的任务执行模块上的任务重新分发给其他未宕机的任务执行模块，以避免任务的延误。

可选地，该方法由任务调度模块执行，且该方法进一步包括：当任务调度模块的重启操作执行完毕时，检查预设时段内的各个待执行任务；根据检查结果确定遗失任务，将遗失任务分发给至少一个任务执行模块。具体地，为了提升可靠性，当任务调度模块的调度重启时，检查预设时段内，例如检查最近1天或最近3小时(具体时间可由参数配置)在生命周期内的任务，如果发现这些任务没有被初始化，说明这些任务在重启、升级期间丢失，则将这些任务确定为遗失任务，并对这些任务进行初始化及运行。具体检查时，可以通过与数据库进行比对的方式进行检查。另外，该遗失任务不同于上文提到的遗漏任务。该遗失任务通常是指：由于任务调度模块的重启过程而导致部分任务未能分发至任务执行模块，将这些由于重启操作而未下发至任务执行模块的任务称作遗失任务。遗漏任务通常是指：任务调度模块已通过常规流程分发至任务执行模块，但是，由于任务调度模块下发给任务执行模块的消息丢失或者由于任务执行模块返回给任务调度模块的消息丢失而导致任务调度模块未接收到执行结果的任务。换言之，遗失任务是指任务调度模块根本未执行下发操作的任务，遗漏任务是指任务调度模块执行了下发操作，但与下发操作相关的消息在异步通信过程中丢失的任务。由此可见，通过本发明中的方式，无论任务在哪一环节丢失，均能够有效恢复。

由此可见，本发明中的任务调度方法能够采用多种容错机制进行容错处理，提升了任务的可靠性，能够有效防止任务丢失、系统异常导致任务不能监控、或者系统升级期间任务丢失等。例如，该方法能够针对任务调度模块重启的情况、任务执行模块宕机的情况、任务调度模块与任务执行模块之间消息传输异常等三种情况进行容错处理，容错机制全面可靠，能够做到任务的零丢失。

实施例五、

图5示出了本发明实施例五提供的一种分布式任务调度系统的结构示意图。图5所示的分布式任务调度系统与图1所示的分布式任务调度系统可以为同一个系统，图5对应的实施例侧重于从服务稳定性的角度描述该系统，图1对应的实施例侧重于从系统整体架构的角度描述该系统，相应地，图5对应的实施例中描述的各个技术特征与图1对应的实施例中描述的各个技术特征可相互结合。当然，本领域技术人员能够理解的是，图5所示的分布式任务调度系统也可以采用不同于图1所示的分布式任务调度系统的架构方式实现，本发明对图5所示的分布式任务调度系统的具体架构不做限定。

如图5所示，该分布式任务调度系统，包括：用于存储待执行任务的任务信息的数据库50、多个任务调度模块51以及多个任务执行模块52；其中，任务调度模块51，适于判断待下发给任务执行模块的任务调度消息是否属于预设类型的消息；若是，将该任务调度消息按照预设的一致性策略下发给任务执行模块52；任务执行模块52，适于根据接收到的任务调度消息执行对应的任务，并向任务调度模块51返回任务响应消息；其中，预设类型的消息包括：消息产生过程中需要访问数据库中存储的任务信息的消息。

其中，数据库可位于实施例一提到的前端交互模块与任务调度模块之间，用于提供数据存储功能。

由此可见，在本实施例提供的分布式任务调度系统中，设置了用于存储待执行任务的任务信息的数据库、多个任务调度模块以及多个任务执行模块。其中，多个任务调度模块以及多个任务执行模块相互并行工作，提升了整个系统的并发量，解决了因单台机器资源不够所导致的性能瓶颈。并且，各个任务调度模块能够在判断出待下发给任务执行模块的任务调度消息属于预设类型的消息时，将该任务调度消息按照预设的一致性策略下发给任务执行模块。其中，预设类型的消息包括消息产生过程中需要访问数据库中存储的任务信息的消息。由此可见，通过该一致性策略能够防止多个任务调度模块同时访问数据库所导致的数据不一致问题，提升服务稳定性。

具体地，在本实施例中，预先针对任务调度模块以及任务执行模块之间传输的各类消息进行了拆分和分类。实际情况中，任务调度模块以及任务执行模块之间传输的消息可能包括多种类型，例如，包括用于实现任务调度模块与任务执行模块之间的任务计算模型的同步的消息、用于监测任务执行模块的系统运行状态的消息、用于向任务执行模块下发任务的消息、用于接收任务执行模块的任务执行结果的消息等。针对上述各种类型的消息，按照消息产生过程是否需要访问数据库中存储的任务信息，将消息划分为预设类型的消息以及非预设类型的消息两大类。由此可见，预设类型的消息是需要访问数据库的消息，由于访问数据库的操作属于重要性较高的操作，并且，由于本发明中的任务调度模块为多个，为了防止多个任务调度模块同时访问数据库所导致的数据不一致问题，在本实施例中，针对预设类型的消息设置了预设的一致性策略，该一致性策略用于确保数据库中数据的一致性，进而确保服务的稳定性。

在本实施例中，上述一致性策略包括：从多个任务调度模块中选举一台主用调度模块，由该主用调度模块访问数据库并将属于预设类型的消息下发给任务执行模块。具体地，预先从多个任务调度模块中选举一台主用调度模块，凡是属于预设类型的消息均交由该主用调度模块负责处理。也就是说，在同一时间内，仅有一台主用调度模块允许访问数据库，其他任务调度模块不允许访问数据库，相应地，任务调度模块采用单点模式向任务执行模块发送从数据库中读取的消息，即：只有一个任务调度模块提供这种服务，其余任务调度模块不提供这种服务。如果主用调度模块挂掉，则从剩余的任务调度模块中重新选举一台主用调度模块。

相应地，任务执行模块向任务调度模块发送任务响应消息等各类消息时，将任务响应消息按照预设规则发送给多个任务调度模块中的一个任务调度模块，以供该任务调度模块根据任务响应消息中包含的任务标识进行处理。其中，预设规则包括：随机发送规则、和/或根据任务标识进行发送的规则。实际情况中，采用发布/订阅模式，任务执行模块随机向任务调度模块发送消息，且每个消息只发送一次。收到该消息的任务调度模块针对该消息进行相关操作，不会存在同一个消息同时发送给两个以上的任务调度模块的情况。

由此可见，本实施例通过消息拆分和分类的方式，将预设类型的消息由主用调度模块发送，避免了多台任务调度模块同时访问数据库所导致的潜在的数据篡改或不一致问题。并且，接收响应消息时，多台任务调度模块同时接收，接收到响应消息的模块直接根据数据库中的相关记录对接收到的消息进行处理即可。

另外，为了进一步提升系统可靠性，本实施例中的每个任务调度模块都由两个互为备份的任务调度子模块组成，同一时间内，其中的一个任务调度子模块负责工作，另一个任务调度子模块处于冗余备份状态。同理，本实施例中的每个任务执行模块也都由两个互为备份的任务执行子模块组成，同一时间内，其中的一个任务执行子模块负责工作，另一个任务执行子模块处于冗余备份状态。一旦某个原本处于工作状态的子模块宕机或出错，处于冗余备份状态的子模块即可立即接替宕机或出错的子模块的工作，从而不影响系统的正常运行。

另外，在本实施例的其他实现方式中，还可以采用如下一致性策略实现。该一致性策略包括：根据任务调度模块对应的哈希值，从数据库中获取与该哈希值对应的待执行任务的任务信息；根据获取到的待执行任务的任务信息中包含的任务标识，从多个任务执行模块中选择与该任务标识匹配的任务执行模块作为目标执行模块；将获取到的待执行任务的任务信息所对应的任务调度消息下发给目标执行模块。其中，每个任务调度模块对应的哈希值是唯一的，每个任务调度模块根据其对应的哈希值，从数据库中获取信息时，仅获取与该哈希值对应的信息。也就是说，预先将数据库中的全部信息根据哈希值划分为多个部分，每一部分分别对应于一个哈希值，相应地，每个任务调度模块仅能够访问数据库中与其哈希值相对应的部分内容，而无权访问其余内容，从而提升了数据库中内容的安全性，避免了数据库中的同一内容同时被多个任务调度模块访问的情况。另外，获取到的每个待执行任务的任务信息中包含任务标识，根据该任务标识能够从多个任务执行模块中选择与该任务标识匹配的任务执行模块作为目标执行模块，例如，可以对该任务标识进行取余运算，根据运算结果确定对应的任务执行模块；又如，还可以预先设置任务标识与任务执行模块之间的对应关系，根据该对应关系确定匹配的任务执行模块，总之，通过任务标识能够快速确定对应的任务执行模块，防止同时将一个任务发给多个任务执行模块的情况发生。

总而言之，通过本实施例中的方式，能够确保数据库中的内容的安全性，防止多个任务调度模块同时获取到相同的任务，并将该相同的任务分别发送给不同的任务执行模块的情况发生。并且，同时多台任务调度模块同时接收消息的方式还能够大幅提升系统的并发量。

另外，可选地，该系统进一步包括：一致性模块53，与各个任务调度模块以及各个任务执行模块分别相连，用于检测并维护各个任务调度模块以及各个任务执行模块之间的一致性。具体地，该一致性模块能够访问各个任务调度模块以及各个任务执行模块上的数据内容，并根据系统日志以及数据库中的记录来判断各个任务调度模块以及各个任务执行模块的状态是否一致，若不一致，则向对应的任务调度模块或任务执行模块发送更新消息，以更新任务调度模块或任务执行模块状态，以满足一致性需求。

可选地，任务调度模块进一步适于：将待执行任务所对应的任务调度消息分发给各个任务执行模块之后，在数据库中记录各个任务执行模块对应的已分发任务；接收各个任务执行模块每隔预设时间周期返回的任务状态列表，根据该任务状态列表中包含的模块标识信息确定发送该任务状态列表的任务执行模块；从数据库中查询与所述发送该任务状态列表的任务执行模块对应的已分发任务；将该任务状态列表与查询到的已分发任务进行比对，根据比对结果确定需要重发的任务，将需要重发的任务分发给至少一个任务执行模块。可选地，任务调度模块具体适于：若该任务状态列表中包含的任务数量小于查询到的已分发任务，则进一步根据各个任务的任务标识确定遗漏任务，所述遗漏任务为查询到的已分发任务中未包含在该任务状态列表中的任务，将所述遗漏任务确定为所述需要重发的任务。其中，所述任务状态列表中的各个任务具有对应的时间戳信息，所述时间戳信息用于描述该任务的初始化时间、运行时间和/或完成时间；则任务调度模块具体适于：当对应于同一任务标识的任务为多个时，根据多个对应于同一任务标识的任务的时间戳信息，从多个对应于同一任务标识的任务中筛选一个任务作为有效任务；根据筛选后的有效任务统计该任务状态列表中包含的任务数量。其中，任务状态列表中的各个任务具有对应的状态信息，任务调度模块具体适于：根据该任务状态列表中的各个任务的状态信息确定所述需要重发的任务；其中，所述状态信息包括：初始化信息、运行信息、运行成功信息、运行失败信息、最后更新时间信息。可选地，任务调度模块具体适于：获取任务的状态信息中包含的最后更新时间；判断当前系统时间与所述最后更新时间之间的时间差是否大于预设宕机阈值；若是，则确定该任务为需要重发的任务；其中，所述预设宕机阈值大于系统升级时长。可选地，任务调度模块进一步适于：当重启操作执行完毕时，检查预设时段内的各个待执行任务；根据检查结果确定遗失任务，将遗失任务分发给至少一个任务执行模块。

本实施例中的分布式任务调度系统可与实施例二中的任务恢复方法以及实施例三和实施例四中的任务调度方法结合使用。尤其可与实施例四中包含多种容错机制的任务调度方法相结合，以便提升服务的稳定性和可靠性。

实施例六、

图6示出了本发明实施例六提供的一种任务调度系统的结构示意图。图6所示的任务调度系统与图1所示的分布式任务调度系统可以为同一个系统，图6对应的实施例侧重于从任务计算模型的角度描述该系统，图1对应的实施例侧重于从系统整体架构的角度描述该系统，相应地，图6对应的实施例中描述的各个技术特征与图1对应的实施例中描述的各个技术特征可相互结合。当然，本领域技术人员能够理解的是，图6所示的任务调度系统也可以采用不同于图1所示的分布式任务调度系统的架构方式实现，本发明对图6所示的任务调度系统的具体架构不做限定。

如图6所示，该任务调度系统包括：任务调度模块61以及多个任务执行模块62，其中，任务调度模块61，用于预先生成多个不同类型的预设的任务计算模型并将任务计算模型下发给各个任务执行模块，并且，进一步用于将获取到的待执行任务下发给各个任务执行模块；任务执行模块62，用于预先接收并存储来自任务调度模块的多个不同类型的预设的任务计算模型，并且，进一步用于根据任务调度模块下发的待执行任务的任务类型从多个不同类型的预设的任务计算模型中调用与任务类型相匹配的任务计算模型，以解析得到待执行任务中的任务参数并根据任务参数运行任务；其中，任务执行模块上存储的各个任务计算模型能够与任务调度模块中生成的各个任务计算模型进行同步。

由此可见，在本实施例提供的任务调度系统中，由任务调度模块预先生成多个不同类型的预设的任务计算模型并下发给各个任务执行模块，任务执行模块根据待执行任务的任务类型从多个不同类型的预设的任务计算模型中调用与任务类型相匹配的任务计算模型，以解析得到待执行任务中的任务参数并根据任务参数运行任务。并且，任务执行模块上存储的各个任务计算模型还能够与任务调度模块中生成的各个任务计算模型进行同步。由此可见，该方式预先创建了多个不同类型的预设的任务计算模型，分别用于解析并运行对应类型的任务，由于同类任务的运行流程大体相似，因此，通过任务计算模型能够快速处理同类型的任务，避免了任务执行模块逐一解析任务并实时创建任务执行程序的繁琐过程，有利于大量任务的并发执行，任务运行效率得以大幅提升。

具体实施时，调度系统中运行的任务都会依赖一个任务计算模型。每个任务计算模型用于处理相同类型的任务。任务的类型可以根据任务的执行流程等因素灵活确定。发明人在实现本发明的过程中发现：针对相同类型的多个任务而言，不同的任务之间只是参数不同，解析方式以及执行流程大体相似。基于该发现，本发明将解析方式以及执行流程相似的任务划分为同一类型的任务，并针对该类型的任务设置对应的任务计算模型，用以解析或执行对应的任务。由此可见，本实施例能够根据任务类型和/或任务执行流程设置各个任务计算模型。本实施例中的任务计算模型不仅能够用于运行与任务相关的运算操作，也能够用于实现任务执行模块的升级。例如，当系统根据实际业务需求的调整，需要对任务执行模块升级时，可以通过对任务执行模块上的各个任务计算模型进行升级实现。为此，本实施例提供了两种用于使任务执行模块上存储的各个任务计算模型能够与任务调度模块中生成的各个任务计算模型相互同步的方式，以实现任务计算模型的更新操作。通过该方式，能够将需要升级的所有任务执行模块或者特定的一组任务执行模块上的任务计算模型进行升级。

第一种模型同步方式为模型下发方式，主要应用于人为上传新的模型包之后的同步过程。在第一种模型同步方式中，任务调度模块主要用于执行以下操作：

步骤一、生成待下发的任务计算模型之后，在预设的模板状态表中插入一条与该待下发的任务计算模型相对应的数据记录，将该数据记录的状态设置为待同步状态。

其中，待下发的任务计算模型可通过页面上传模板的方式生成，例如，可以通过图1所示的前端交互模块上传最新版本的任务计算模型的模板，然后，由前端服务器(例如WEB服务器)将上传的模板保存到预设目录下，并生成一个对应于该模板的下载地址，然后在模板状态表中插入一条数据记录，用以记录该模板，并将其状态设置为待同步。

其中，该模板状态表用于存储系统中全部的任务计算模型，以便实现对各个任务计算模型的统一监管。该模板状态表中的每条数据记录至少要存储对应的任务计算模型的标识以及对应的状态(如待同步、已同步、已使用等等)。

步骤二、扫描该模板状态表，分别针对扫描到的处于待同步状态的每个数据记录生成对应的同步任务。

由于系统中不断有新的模板上传，因此，可以周期性扫描模板状态表，为扫描到的处于待同步状态的每个数据记录生成对应的同步任务。具体地，从多个任务执行模块中确定与该数据记录对应的至少一个任务执行模块；针对该数据记录生成对应于至少一个任务执行模块的至少一个同步任务。其中，当与该数据记录对应的至少一个任务执行模块为多个时，针对该数据记录生成对应于至少一个任务执行模块的至少一个同步任务时，针对该数据记录生成多个分别对应于各个与该数据记录对应的任务执行模块的同步任务。实际情况中，一条待同步的数据记录中的任务计算模型可能仅针对于特定的一台任务执行模块，此时，根据该数据记录中的任务计算模型所对应的一台任务执行模块生成对应于该台任务执行模块的同步任务。或者，一条待同步的数据记录中的任务计算模型可能通用于全部的任务执行模块，此时，针对该数据记录中的任务计算模型，生成多个分别对应于每一任务执行模块的同步任务，即：同步任务的数量等于任务执行模块的数量。

步骤三、将同步任务下发至对应的任务执行模块，以供任务执行模块根据同步任务同步对应的任务计算模型。

可选地，在将同步任务下发至对应的任务执行模块之后，进一步将同步任务对应的数据记录的状态更新为同步进行状态；然后，周期性扫描模板状态表中包含的状态为同步进行状态的数据记录；针对扫描到的数据记录，查询对应的任务执行模块的同步任务执行结果；根据查询到的同步任务执行结果，将对应的数据记录的状态更新为同步成功状态或同步失败状态，以便跟进各个同步任务的执行结果，从而针对失败的任务重新运行。

第二种模型同步方式为主动上报方式，也称作任务执行模块的自我检查模式，在第二种同步方式中，每一个任务执行模块定时向任务调度模块发送自身机器上的各个任务计算模型的版本信息。任务调度模块接收到任务执行模块上报的各个任务计算模型的版本信息之后，和数据库中记录的版本信息进行对比，将结果不一致时，则会创建用于向对应的任务执行模块定向同步任务计算模型的同步任务。

由此可见，在第二种模型同步方式中，各个任务执行模块进一步用于：定期获取并上报该任务执行模块上存储的各个任务计算模型的版本信息；任务调度模块进一步用于：将各个任务执行模块上报的各个任务计算模型的版本信息与数据库中记录的各个任务计算模型的版本信息进行比对，当比对结果不一致时，根据比对结果生成用于向任务执行模块同步任务计算模型的同步任务。其中，为了便于传输且加快比对时间，该任务执行模块上存储的各个任务计算模型的版本信息包括：各个任务计算模型的版本号的MD5值。相应地，各个任务执行模块周期上报本模块上已有的各个任务计算模型的模板MD5给任务调度模块，若任务调度模块发现某个任务执行模块上报的模板MD5与模板表中存储的内容不一致，例如，版本信息不一致或者任务执行模块缺少某模板，则需要重新向该任务执行模块同步相应的模板。

本实施例中的任务类型包括：实时任务类型和/或离线任务类型，相应地，任务计算模型包括：与实时任务类型相对应的任务计算模型和/或与离线任务类型相对应的任务计算模型，每类模型分别针对相应任务的特点进行设置，有利于高效地处理相应任务。

另外，本实施例中的任务调度模块可以进一步用于：监测各个任务执行模块的系统运行状态，根据监测结果向各个任务执行模块下发待执行任务；其中，系统运行状态包括以下中的至少一个：CPU状态、内存状态、磁盘使用率、任务并发数。由此可见，该方式预先创建了多个不同类型的预设的任务计算模型，分别用于解析并运行对应类型的任务，由于同类任务的运行流程大体相似，因此，通过任务计算模型能够快速处理同类型的任务，避免了任务执行模块逐一解析任务并实时创建任务执行程序的繁琐过程，有利于大量任务的并发执行，任务运行效率得以大幅提升。并且，该方式通过两种同步方式能够实现任务计算模型的升级操作，进而实现任务执行模块的升级。即：本实施例将任务执行模块的升级操作转化为任务计算模型的同步操作，从而利用任务计算模型实现了任务执行模块的升级，简化了升级过程，提升了升级效率。若采用常规方式对任务执行模块进行升级，必须借助第三方工具对任务执行模块进行整体性升级，该方式势必会造成任务执行模块的运行过程中断，而采用本发明中的任务计算模型的同步操作，借由任务计算模型升级间接实现任务执行模块的升级时，可针对任务执行模块中的部分模型进行升级(无需针对任务执行模块整体升级)，无需中断该任务执行模块上的全部任务的运行，升级过程快捷方便。

本领域技术人员能够理解的是，在实施例一至实施例六中，任一实施例中的技术特征均能够与其他一个或多个实施例中的技术特征相互结合。另外，在本发明提供的系统中，进一步提供了如下辅助功能：为了支持其他平台通过服务化API向调度系统提交任务，势必会存在两个平台之间的任务运行状态、日志信息同步的问题。为解决两个平台之间的同步问题，本发明中的系统向这些平台提供了任务状态查询接口和日志获取接口。另外，为了能够主动向平台发送任务相关的通知消息，还提供了任务状态和日志回调机制，具体地，在任务创建时，任务中提供两个回调接口：任务状态接口以及任务日志接口。其中，任务状态接口用于在任务调度模块更新数据库时同时将与更新相关的任务状态信息发送到任务回调接口中，以供其他平台接收。任务日志接口用于提供给任务调度模块以便将日志按照增量的模式发送给回调接口，并提供了断点续传功能，如果在调度重启后，该任务的日志还会接着从最后一次上传的点，开始续传日志，直到该任务运行结束。

综上所述，本发明实施例一至实施例六中描述的各个系统及方法提供了一套完整的任务调度机制。该任务调度机制至少具备如下特点：采用分布式架构实现、任务调度模块以及任务执行模块都为多台机器，提高了任务稳定性。每台任务执行模块可同时最大并发50多个任务，并发量大。支持任务容错功能：包括任务状态检查、任务重新调度、机器下线重新调度任务等机制。支持任务恢复功能：系统升级期间不影响任务执行。支持多种类型的任务：可根据业务需求指定不同的计算模型(支持离线、实时任务)。支持任务路由功能：提供任务随机执行和指定机器执行的功能。系统监控：可以监控机器内存、CPU、负载、磁盘等指标，并根据监测结果采用相应的任务调度策略。支持任务拓扑功能：提供任务依赖拓扑(支持不同维度之间的任务依赖)，支持拓扑暂停、拓扑恢复等功能。模型升级：支持任务计算模型的下发和模型自我检查机制，可以对任务计算模型进行升级，从而间接实现对任务执行模块的升级。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例中的基于分布式系统的业务处理装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (12)

1.一种分布式任务调度系统，包括：用于存储待执行任务的任务信息的数据库、多个任务调度模块以及多个任务执行模块；其中，多个任务调度模块以及多个任务执行模块相互并行工作，

任务调度模块，适于判断待下发给任务执行模块的任务调度消息是否属于预设类型的消息；若是，将该任务调度消息按照预设的一致性策略下发给任务执行模块；

任务执行模块，适于根据接收到的任务调度消息执行对应的任务，并向任务调度模块返回任务响应消息；

其中，所述预设类型的消息包括：消息产生过程中需要访问所述数据库中存储的任务信息的消息；

所述一致性策略包括：从多个任务调度模块中选举一台主用调度模块，由所述主用调度模块访问所述数据库并将属于预设类型的消息下发给任务执行模块；

在同一时间内，仅有一台主用调度模块允许访问数据库，其他任务调度模块不允许访问数据库；

任务调度模块采用单点模式向任务执行模块发送从数据库中读取的消息。

2.根据权利要求1所述的系统，其中，所述一致性策略包括：根据任务调度模块对应的哈希值，从数据库中获取与该哈希值对应的待执行任务的任务信息；

根据获取到的待执行任务的任务信息中包含的任务标识，从多个任务执行模块中选择与该任务标识匹配的任务执行模块作为目标执行模块；

将获取到的待执行任务的任务信息所对应的任务调度消息下发给所述目标执行模块。

3.根据权利要求1或2所述的系统，其中，各个任务调度模块具体适于：将任务响应消息按照预设规则发送给多个任务调度模块中的一个任务调度模块，以供该任务调度模块根据任务响应消息中包含的任务标识进行处理。

4.根据权利要求3所述的系统，其中，所述预设规则包括：随机发送规则、和/或根据任务标识进行发送的规则。

5.根据权利要求1或2所述的系统，其中，所述系统进一步包括：一致性模块，与各个任务调度模块以及各个任务执行模块分别相连，用于检测并维护各个任务调度模块以及各个任务执行模块之间的一致性。

6.根据权利要求1或2所述的系统，其中，所述任务调度模块进一步适于：将待执行任务所对应的任务调度消息分发给各个任务执行模块之后，在数据库中记录各个任务执行模块对应的已分发任务；接收各个任务执行模块每隔预设时间周期返回的任务状态列表，根据该任务状态列表中包含的模块标识信息确定发送该任务状态列表的任务执行模块；从数据库中查询与所述发送该任务状态列表的任务执行模块对应的已分发任务；将该任务状态列表与查询到的已分发任务进行比对，根据比对结果确定需要重发的任务，将所述需要重发的任务分发给至少一个任务执行模块。

7.根据权利要求6所述的系统，其中，所述任务调度模块具体适于：若该任务状态列表中包含的任务数量小于查询到的已分发任务，则进一步根据各个任务的任务标识确定遗漏任务，所述遗漏任务为查询到的已分发任务中未包含在该任务状态列表中的任务，将所述遗漏任务确定为所述需要重发的任务。

8.根据权利要求7所述的系统，其中，所述任务状态列表中的各个任务具有对应的时间戳信息，所述时间戳信息用于描述该任务的初始化时间、运行时间和/或完成时间；

则所述任务调度模块具体适于：当对应于同一任务标识的任务为多个时，根据多个对应于同一任务标识的任务的时间戳信息，从所述多个对应于同一任务标识的任务中筛选一个任务作为有效任务；根据筛选后的有效任务统计该任务状态列表中包含的任务数量。

9.根据权利要求6所述的系统，其中，所述任务状态列表中的各个任务具有对应的状态信息，所述任务调度模块具体适于：根据该任务状态列表中的各个任务的状态信息确定所述需要重发的任务；

其中，所述状态信息包括：初始化信息、运行信息、运行成功信息、运行失败信息、最后更新时间信息。

10.根据权利要求9所述的系统，其中，所述任务调度模块具体适于：获取任务的状态信息中包含的最后更新时间；判断当前系统时间与所述最后更新时间之间的时间差是否大于预设宕机阈值；若是，则确定该任务为需要重发的任务；其中，所述预设宕机阈值大于系统升级时长。

11.根据权利要求6所述的系统，其中，所述任务调度模块进一步适于：当重启操作执行完毕时，检查预设时段内的各个待执行任务；根据检查结果确定遗失任务，将遗失任务分发给至少一个任务执行模块。

12.根据权利要求11所述的系统，其中，所述任务调度模块与各个任务执行模块之间采用异步通信方式进行通信。

Images