CN113204419A

CN113204419A - 一种超大规模任务调度分发处理方法、系统及计算机可读存储介质

Info

Publication number: CN113204419A
Application number: CN202110580855.6A
Authority: CN
Inventors: 张启欣
Original assignee: Shenzhen Lingxing Network Technology Co ltd
Current assignee: Shenzhen Lingxing Network Technology Co ltd
Priority date: 2021-05-26
Filing date: 2021-05-26
Publication date: 2021-08-03
Anticipated expiration: 2041-05-26
Also published as: CN113204419B

Abstract

本申请涉及一种超大规模任务调度分发处理方法、系统及计算机可读存储介质，其包括基于自身状态发送任务领取请求，从数据库中获取处于未调度状态的任务配置表；任务配置表内包含用于指示任务执行的数据；根据获取的任务配置表，向数据库发送任务领取回执；数据库根据接收的任务领取回执，将任务领取回执对应的任务配置表修改为与任务回执对应的任务调度单元相绑定的占用状态；识别绑定的任务配置表，构建对应于任务配置表的任务实例；分发任务实。各个任务调度单元之间建立了支持水平扩容的高可用任务调度层，各个处于空闲状态的任务调度单元均可处理数据，具有支持大规模的任务调度性能的特点。

Description

一种超大规模任务调度分发处理方法、系统及计算机可读存储介质

技术领域

本申请涉及任务调度技术的领域，尤其是涉及一种超大规模任务调度分发处理方法、系统及计算机可读存储介质。

背景技术

云计算是一种以互联网为中心的网络应用概念，目前已经逐渐衍变成一个集大数据量运算和存储为一体的高性能计算机的集中地。在云计算中，为了能够使大量的任务能够高效地并行执行，需要使用任务调度系统来完成系统配置、作业管理和运行监控等操作。

相关技术中如申请公布号为CN102521044A的中国发明专利申请公开了一种基于消息中间件的分布式任务调度方法，该申请的方法包括以下步骤：

（1）将待处理的任务保存到主节点的任务队列中；

（2）将任务队列中的任务通过消息中间件由负载均衡管理器均衡分配到主节点下的可用子节点中；

（3）启动子节点的任务进程，由子节点的目标主机执行子节点的任务。

针对上述技术方案，发明人认为该系统支持的任务管理量较少，当任务管理量较大时该系统的稳定性较差，发生任务分发卡死的几率也会增大。

发明内容

本申请目的一是提供一种超大规模任务调度分发处理方法，具有提高系统在大规模任务调度时工作稳定性的特点。

本申请的上述发明目的一是通过以下技术方案得以实现的：

一种超大规模任务调度分发处理方法，包括：

至少两个任务调度单元从数据库中获取处于未调度状态的任务配置表；其中，所述任务配置表内包含用于指示任务执行的任务信息；

数据库将被任务调度单元获取的任务配置表修改为与对应的任务调度单元相绑定的占用状态；其中，任意一个处于占用状态的所述任务配置表只能与其中一个任务调度单元绑定；

任务调度单元识别绑定的任务配置表内的任务信息，构建对应于任务配置表的任务实例；

分发任务实例，将已分发的任务实例对应的任务配置表修改为已调度状态。

通过采用上述技术方案，各个任务调度单元之间建立了支持水平扩容的高可用任务调度层，多个任务调度单元均可独立完成领取任务配置表、识别任务信息、构建任务实例和分发任务实例等工作，以提高大规模任务调度时的系统工作性能，减少任务分发卡死的几率。当任务配置表处于占用状态或已调度状态时，任务配置表不能被调度，利用这种查询任务配置表调度状态的判断机制，减少了单个任务被重复调度的几率，使各个任务调度单元之间的独立运行更加安全，降低多个任务调度单元发生冲突死锁的风险，提高工作稳定性。

可选的，上述方法还包括：

至少两个处理单元领取任务调度单元分发的任务实例；其中，每一个所述任务实例包括至少一个任务项目；各个处理单元均能够独立处理任务项目；

处理单元处理自身领取的任务项目。

通过采用上述技术方案，各个处理单元之间建立了分布式工作节点，可同时独立处理多个任务项目，并且提供多种任务处理框架，提高任务处理效率，使任务调度效率与任务处理效率相匹配。

可选的，所述分发任务实例的具体方法为：

将任务实例分发至中间件中；其中，所述中间件用于缓存各个任务实例以供用于处理任务实例的处理单元领取。

通过采用上述技术方案，中间件可以缓存各个任务实例，并在各个处理单元需要领取任务实例时进行快速分配。

可选的，上述方法还包括：

在数据库中生成对应于任务配置表的任务执行状态表；

其中，所述任务执行状态表关联于任务配置表所对应的任务实例，任务执行状态表用于记录对应任务实例的处理状态，任务执行状态能够被用于处理任务实例的处理单元修改。

通过采用上述技术方案，处理单元可根据自身领取的任务实例的处理状态，实时记录在任务执行状态表上，以供其他应用程序进行读取。

可选的，所述任务实例内的各个任务项目之间能够具有依赖关系；

所述处理单元能够通过自动方式或手动方式重新处理自身领取的任务项目。

通过采用上述技术方案，由于工作流中的各个任务项目由多个处理单元独立处理，因此，工作流上每个任务项目都是原子可重试的，一个工作流某个环节的任务项目失败之后，对应的处理单元可自动或手动进行重试，不必从头开始工作流。

可选的，所述任务调度单元包括有等待任务配置表的空闲状态和正在识别任务配置表的忙碌状态；

当任务调度单元处于空闲状态时，所述任务调度单元定时从数据库中获取处于未调度状态的任务配置表；

当任务调度单元处于忙碌状态时，所述任务调度单元暂定从数据库中获取处于未调度状态的任务配置表。

通过采用上述技术方案，当任务调度单元处于忙碌状态时，任务调度单元暂时停止获得任务配置表，减少任务配置表在单一任务调度单元上堆积过多的情况的发生。

可选的，上述方法还包括：

根据各个任务配置表的状态，通过可视化的方式显示对应的各个任务配置表的调度状态；

根据各个任务执行状态表，通过可视化的方式显示对应的各个任务实例的处理状态。

通过采用上述技术方案，系统通过可视化的任务管理页面显示所有的任务配置表的调度状态，以供用户监控所有任务的分发；同理，系统还通过可视化的任务管理页面显示所有的任务实例的处理状态，以供用户监控所有任务的处理进程，从而方便使用者监控管理各个任务从开始创建到处理结果之间的节点。

可选的，所述方法还包括：

实时检测各个任务调度单元的工作状态，并根据各个任务调度单元的工作状态，向用户端发送对应于任务调度单元的任务告警信息。

通过采用上述技术方案，系统能够实时监控任务调度单元的工作状态，当任务调度单元处于异常状态，如多个任务调度单元发生冲突、任务调度单元工作效率过低等情况发生时，系统会触发相应的任务告警信息，向用户发出警报。

本申请目的二是提供一种超大规模任务调度分发处理方法，具有提高系统在大规模任务调度时工作稳定性的特点。

本申请的上述发明目的二是通过以下技术方案得以实现的：

一种超大规模任务调度分发处理方法，包括：

获取配置有任务信息的任务模板，根据任务模板的任务信息，在数据库中生成与任务模板一一对应的任务配置表；其中，任务配置表的状态包括未调度状态、占用状态和已调度状态；

根据调度集群中的任务调度单元发送的任务领取请求，从数据库中分配处于未调度状态的任务配置表至对应的任务调度单元；其中，调度集群中包括至少两个能够独立工作的任务调度单元；

根据任务调度单元领取任务配置表后发送的任务领取回执，将任务领取回执对应的任务配置表修改为与任务领取回执对应的任务调度单元相绑定的占用状态；其中，任意一个处于占用状态的任务配置表只能与其中一个任务调度单元绑定；

任务调度单元根据绑定的任务配置表构建任务实例，并将任务实例对应的任务配置表修改为已调度状态。

本申请目的三是提供一种超大规模任务调度分发处理系统，具有提高系统在大规模任务调度时工作稳定性的特点。

本申请的上述发明目的三是通过以下技术方案得以实现的：

数据库，用于储存各个任务配置表；其中，所述任务配置表的状态包括未调度状态、占用状态和已调度状态；

调度集群，包括至少两个能够独立工作的任务调度单元；

所述任务调度单元能够从数据库中获取处于未调度状态的任务配置表，且当任意一个任务调度单元获取了其中一个任务配置表之后，任务配置表被修改为与对应任务调度单元相绑定的占用状态；

所述任务调度单元能够通过识别相绑定的任务配置表内的任务信息，以构建对应于任务配置表的任务实例；

所述任务调度单元能够分发构建完成的任务实例，当任意一个任务实例被分发之后，对应于任务实例的任务配置表修改为已调度状态。

可选的，超大规模任务调度分发处理系统还包括：

任务配置模块，用于获取任务模板，并根据任务模板内的信息，在所述数据库中生成与任务模板一一对应的任务配置表；

中间件，用于缓存所述任务调度单元分发的任务实例；

处理集群，包括至少两个能够独立工作的处理单元；

所述处理单元能够从中间件领取并处理自身领取的任务实例。

本申请目的四是提供一种计算机存储介质，能够存储相应的程序，具有提高系统在大规模任务调度时工作稳定性的特点。

本申请的上述发明目的四是通过以下技术方案得以实现的：

一种计算机可读存储介质，存储有能够被处理器加载并执行上述任一种超大规模任务调度分发处理方法的计算机程序。

附图说明

图1是本申请的超大规模任务调度分发处理方法的流程示意图。

图2是本申请任务调度单元构建并分发任务实例的流程示意图。

图3是数据库、任务配置表和任务执行状态表的分布示意图。

图4是任务实例、任务项目和并发子项目的划分示意图。

图5是本申请处理单元领取并处理任务项目的流程示意图。

图6是本申请的超大规模任务调度分发处理系统的架构示意图。

图中，1、任务配置模块；2、数据库；3、任务调度单元；4、中间件；5、处理单元；6、任务管理模块；7、实时告警模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面结合说明书附图1-5对本申请实施例作进一步详细描述。

实施例一

本申请实施例提供一种超大规模任务调度分发处理方法，所述方法的主要流程描述如下。

参照图1，S01、在数据库中生成多个任务配置表。

其中，每一个任务配置表均包含有用于指示任务执行的任务信息。

参照图1和图2，在S01的具体方法中，包括：

S011、任务配置平台实时获取任务模板。

其中，任务模板通过录入对应任务参数而生成，任务模板中的任务参数可以为用户手动录入，也可以为系统自动下载录入。以用户手动录入的方式为例，用户能够在任务配置平台的配置页面选择空白模板，并在选择的空白模板上输入任务参数，空白模板和任务参数可组成完整的任务模板。

S012、任务配置平台根据任务模板内的信息，在数据库中生成对应的任务配置表。

其中，每一个任务模板均有一个任务ID，任务配置平台通过提取任务模板的任务参数，可以生成与任务模板具有共同任务ID的任务配置表，并将任务配置表存入数据库中。任务参数内包含有与任务模板相对应的任务信息，能够指示任务符合进行；在本实施例中，任务信息包括有任务类型、任务执行频率、任务所属模块、任务开始时间、任务重试机制和任务失败告警等。

参照图3，所有任务模板相当于通过各个任务配置表的形式存储在数据库中，数据库中多个任务配置表按照特定的顺序配列，组成了任务配置队列，并等待任务调度单元进行调度。

在本实施例中，任务调度单元为调度器；数据库为My SQL数据库；任务配置队列的排列顺序为存入时间递增的顺序。

具体的，每个任务配置表在生成之后均处于等待被调度的状态，而当任务配置表所对应的任务被调度走之后，任务配置表则改为调度完成的状态。因此，任务配置表的状态包括有未调度状态和已调度状态。任务配置表中包含有用于反映任务的调度状态的调度状态参数，通过修改调度状态参数，可指示任务配置表的未调度状态或已调度状态。

另外的，任务配置表的状态还包括有占用状态，占用状态指的是任务配置表已经开始参与任务调度，但任务调度可能未完成的状态。为了避免多个调度器共同识别同一个任务配置表，当任务配置表被任意一个调度器领取走后，该任务配置表便会与对应的任务调度单元相绑定，除了相绑定的任务调度单元可以读取识别该任务配置表的信息，其他所有的任务调度单元均不能继续读取识别该任务配置表，以避免任务配置表被重复调度。

因此，占用状态是介于未调度状态和已调度状态之间的一种状态，占用状态可以分别与未调度状态、已调度状态共存，而不受调度状态参数修改的影响。

参照图2，综上，步骤S011-S012相当于任务配置表初始形成的阶段，用于将人工录入的任务模板转化为任务配置表并在数据库中形成有序队列，以等待被各个任务调度单元领取和调度。

S02、多个任务调度单元从数据库中领取任务配置表，并根据自身领取的任务配置表构建任务实例。

其中，任务配置表在生成之后，需要被任务调度单元领取再进行调度。

参照图2，在S02的具体方法中，包括：

S021、调度集群中的各个任务调度单元基于自身状态向数据库发送任务领取指令。

其中，调度集群中包括有至少两个任务调度单元，每一个任务调度单元均为能够独立工作的任务调度器；在本实施例中，任务调度单元的数量为3。各个任务调度单元均可以获取并识别任务配置表，共享db性能资源，实现调度层的水平扩容以提高调度性能。

具体的，调度群集能够建立高可用的调度模式，即当调度群集的其中一个任务调度单元发生异常后，调度群集的其他任务调度单元可继续执行任务调度，相较于市面上流行的单点调度模式更加稳定和高效，适用于超大规模的任务管理调度中。

任务调度单元的状态包括有忙碌状态和空闲状态，若任务调度单元正在处理获取到的任务配置表，则该任务调度单元处于忙碌状态，暂时停止向数据库请求新的任务配置表；若任务调度单元当前没有任务配置表需要处理，该任务调度单元处于空闲状态，任务调度单元会定时向数据库发送任务领取指令，通过轮询的方式向数据库请求任务配置表。

当任务调度单元处理完上一个任务配置表的任务调度后，任务调度单元会从忙碌状态切换至空闲状态，等待下一个任务配置表进行处理。

其中，对于不同的任务配置表，任务调度单元处理所需要的时间可能也不同，因此，各个任务调度单元之间可能会同时发送任务领取指令，也可能会在不用时间点分别发送任务领取指令。

S022、数据库根据任务调度单元发送的任务领取请求，分发处于未调度状态的任务配置表至对应的任务调度单元。

其中，当数据库接收到任务领取请求后，数据库根据各个任务配置表的调度状态参数，查找处于未调度状态的任务配置表，并将处于未调度状态的任务配置表分发至发送任务领取请求的任务调度单元。其中，数据库有可能会同时接收到多个任务调度单元发送的任务领取请求，但最终一个任务配置表只会被一个任务调度单元处理。

S023、任务调度单元根据获取的任务配置表，向数据库发送任务领取回执。

其中，任务调度单元获取到任务配置表后，会向数据库发送对应于该任务配置表的任务领取回执，以声明自身已经领取到该任务配置表，需要数据库阻止其他任务调度单元再次领取该任务配置表。

S024、数据库判断任务领取回执所对应的任务配置表是否处于占用状态，若是则执行S025；若否则执行S026。

其中，数据库有可能会在同时接收到多个任务领取请求后，将同一个任务配置表分发至多个任务调度单元，在此基础上，为了避免同一个任务配置表被多个任务调度单元重复调度，应只选择其中一个任务调度单元对任务配置表进行识别。因此，在接收到多个任务领取请求时，数据库会依次判断任务配置表是否已经被任意一个任务调度单元占用，以阻止多个任务调度单元继续对任务配置表进行识别。

S025、数据库发送占用回执至发送任务领取回执的任务调度单元，并返回S021。

其中，若任务领取回执对应的任务配置表已经被其中一个任务调度单元绑定，则表明该任务配置表已经被占用，暂时不需要其他任务调度单元调度。因此，数据库需要发送占用回执至其他的任务调度单元，令其他的任务调度单元放弃该任务配置表并重新发送任务领取请求，而其他任务调度单元则可以获取其他的任务配置表。

S026、数据库根据任务调度单元发送的任务领取回执，将对应的任务配置表修改为与对应的任务调度单元相绑定的占用状态。

其中，由于任务领取回执对应的任务配置表尚未被任务调度单元获取，因此，数据库需要将任务配置表与对应的任务调度单元绑定，将任务配置表修改为占用状态。处于占用状态的任务配置表拒绝除绑定关系以外的其他任务调度单元对其进行访问，以阻止一个任务配置表被多个任务调度单元对该任务配置表重复获取，减少多个任务调度单元之间发生冲突死锁的几率。

优选的，数据库将任务配置表修改为占用状态的方式，为对任务配置表修通过行级锁上锁。当数据库接收到任意一个任务领取回执，且对应的任务调度表处于没有上行解锁的状态时，数据库则给该任务配置表加上行级锁，使任务配置表和最先获取该任务配置表的任务调度单元相绑定，在被上锁的状态下，任务配置表只被已经绑定了的任务调度单元读取，从而阻止其他任务调度单元读取该任务配置表。

S027、任务调度单元识别绑定的任务配置表内的任务信息。

其中，任务配置表内包含有任务信息，任务调度单元通过识别这些关键的任务信息，可以构建出具体且完整的任务实例，以供处理单元去处理。

S028、任务调度单元根据获取的任务信息，构建对应于任务配置表的任务实例。

参照图4，其中，每一个任务实例内包含至少一个任务项目，其各个任务项目之间可能存在有依赖关系。当任务实例内的任务项目的数量大于等于2，且多个任务项目之间具有依赖关系时，任务实例内的各个任务项目组成一个工作流；在工作流中，需要完成上一个任务项目才能处理下一个任务项目。

参照图2，S029、任务调度单元根据获取的任务信息，在数据库中生成任务执行状态表。

其中，任务执行状态表指的是能够记录任务实例内的各个任务项目的处理状态的表，可供处理单元进行读写，而其他应用程度也能够通过读取任务执行状态表内的信息，以获知对应的任务实例的处理进程或处理进程。

具体的，任务执行状态表的状态包括有queue（等待队列中）、running（进行中）、stop（暂停中）、fail（任务失败）和end（任务结束）。在本实施例中，任务调度表可反映任务的调度状态，任务执行状态表可反映任务的执行状态，两者配合可反映完整的任务生成、调度和处理状态。

综上，步骤S021- S029相当于任务实例构建的阶段，能够将等待队列中的任务配置表转化为具体且完整的任务实例。

参照图5，S03、任务调度单元分发任务实例，处理单元领取并处理任务调度单元分发的任务实例。

其中，任务调度单元在构建完成任务实例后，需要将任务实例分发给处理单元执行任务。

在S03的具体方法中，包括：

S031、任务调度单元将任务实例分发至中间件中，并将任务实例对应的任务配置表修改为已调度状态。

其中，中间件可以缓存各个任务实例，在本实施例中，任务实例以各个任务项目的形式缓存于中间件；中间件选用MQCluster，中间件的解耦应用选用redis、kafka中的一种或多种组合。

当任务调度单元将任务实例分发至中间件中后，任务调度单元会向数据库发送调度状态修改指令；数据库在接收到调度状态修改指令之后，数据库先修改对应的任务配置表的调度状态参数，将任务配置表修改为已调度状态，然后会解开对应的任务配置表的行级锁，以供其他应用程序访问任务配置表。

S032、处理集群的各个处理单元从中间件中领取任务项目。

其中，处理集群包括有至少两个处理单元，各个处理单元均能够独立处理任务项目。处理单元自身具有一个处理队列，任务项目可放置在处理队列中，处理单元会依次处理处理队列中的所有任务项目。

具体的，每一个处理单元均可以通过轮询的方式，定时向中间件发送任务请求。响应于发送任务请求，若中间件中缓存有任务项目，中间件则会将任务项目分配至发送任务请求的处理单元；处理单元则会将获取的任务项目存入自身的处理队列中。

优选的，处理集群内的处理单元的处理框架为celery、serverless和K8S中的一种或多种。在本实施例中，各个处理单元组成了一个分布式工作节点，从而使一个工作流的多个任务项目可以在多个处理单元上同时执行，提高任务处理效率。

S033、处理单元处理自身领取的任务项目。

参照图4，其中，每一个任务项目内可能包含有并发量个并发子项目，任意一个任务项目被处理时，任务项目内的所有并发子项目会并发处理；在本实施例中，处理单元中的多个线程可以同时处理任务项目内的各个并发子项目。

如其中任务实例内包含有4个并发量为10的任务项目，分别为任务项目 A、任务项目 B、任务项目 C和任务项目 D，四者之间存在的依赖关系为：任务项目 A、任务项目 B、任务项目 C和任务项目 D需要依次完成。当处理单元处理任务实例时，处理单元需要依次处理完任务项目 A、任务项目 B、任务项目 C和任务项目 D，且每当处理单元处理一个任务项目时，处理单元内的10个线程会并发一同处理10个并发子项目。

在本实施例中，处理单元支持自动方式或手动方式去重试任务项目；当多个处理单元共同处理一个任务实例的工作流时，由于工作流中的各个任务项目由多个处理单元独立处理，因此，工作流上每个任务项目都是原子可重试的，即在某个环节的任务项目失败之后，对应的处理单元可自动或手动进行重试，整个工作流不必从头开始。

参照图5，S034、处理单元根据任务项目的处理状态，实时修改任务实例对应的任务执行状态表。

其中，处理单元在依次执行处理队列中的任务项目时，会根据各个任务项目的处理状态或处理进程，修改任务项目对应的任务执行状态表。

综上，步骤S031-S034相当于是各个任务实例分发和处理的阶段，能够通过分布式工作节点处理被调度走的各个任务实例。

在本申请实施例提供的一种超大规模任务调度分发处理方法中，还包括：

任务管理模块根据各个任务配置表的状态，通过可视化的方式显示对应的各个任务配置表的调度状态。

其中，任务管理模块能够读取任务配置表的调度状态参数，来获知各个任务配置表的状态，并通过可视化的方式进行显示。在本实施例中，任务管理模块配置有任务管理页面，任务管理模块能够通过任务管理页面显示所有的任务配置表的调度状态，用户通过查看任务管理页面来监控所有任务的调度进程。

任务管理模块根据各个任务执行状态表，通过可视化的方式显示对应的各个任务实例的处理状态。

其中，任务管理模块能够读取任务执行状态表的信息，来获知各个任务实例的处理状态，并通过可视化的方式进行显示。在本实施例中，任务管理模块能够通过任务管理页面显示所有的任务实例的处理状态，用户通过查看任务管理页面来监控所有任务的处理进程。

优选的，任务管理模块会记录所有任务的调度进程和处理进程，并将记录的所有内容通过Log日志的方式存入ES数据库中。

实时告警模块实时检测各个任务调度单元的工作状态，并根据各个任务调度单元的工作状态，向用户端发送对应于任务调度单元的任务告警信息。

其中，实时告警模块能够实时监控任务调度单元的工作状态，当任务调度单元处于异常状态，如多个任务调度单元发生冲突、任务调度单元工作效率过低等情况发生时，实时告警模块会触发相应的任务告警信息，向用户的邮箱发送任务告警邮件。

本申请实施例一的实施原理为：以有向无环图的方式构建任务依赖关系，各个任务调度单元之间建立了支持水平扩容的高可用任务调度层，多个任务调度单元均可独立完成领取任务配置表、识别任务信息、构建任务实例和分发任务实例等工作，以提高大规模任务调度时的系统工作性能，减少任务分发卡死的几率。利用行级锁的上锁机制，减少了单个任务被重复调度的几率，使各个任务调度单元之间的独立运行更加安全，降低多个任务调度单元发生冲突死锁的风险，提高工作稳定性。

各个处理单元之间形成了分布式工作节点，并且提供多种任务处理框架，提高任务处理效率。由于工作流中的各个任务项目由多个处理单元独立处理，因此，工作流上每个任务项目都是原子可重试的，一个工作流某个环节的任务项目失败之后，对应的处理单元可自动或手动进行重试，不必从头开始工作流。

各个任务调度单元和各个处理单元均做到了高可用高性能的水平扩容方式，通过redis和kafka等中间件的解耦应用，在任务调度单元和处理单元之间实现了任务缓冲和消费能力可控的任务分发，从而搭建一个可用支持百万级任务调度管理的任务编排平台。

另外的，任务配置平台支持人工录入任务模板的方式，构建任务配置表，从而提供可扩展的工作流定制服务，更加灵活方便。任务管理页面支持可视化的任务粒度跟踪，供用户查看各个任务的调度状态和处理状态。实时告警模块能够实时监控任务调度单元的工作状态，当任务调度单元处于异常状态，实时告警模块可及时向用户的邮箱发送任务告警邮件，通知相关负责人及时查看处理。

实施例二：

参照图6，在一个实施例中，提供一种超大规模任务调度分发处理系统，与上述实施例一中的超大规模任务调度分发处理方法一一对应，包括：

任务配置模块1，用于生成任务配置平台以获取各个任务模板，并根据任务模板内的任务信息，生成与任务模板一一对应的任务配置表；其中，任务配置表的状态包括未调度状态、占用状态和已调度状态。

数据库2，用于储存各个任务配置表和各个任务执行状态表。

调度集群，包括至少两个能够独立工作的任务调度单元3；

任务调度单元3能够从数据库2中获取处于未调度状态的任务配置表，且当任意一个任务调度单元3获取了其中一个任务配置表之后，任务配置表被修改为与该任务调度单元3相绑定的占用状态；

任务调度单元3能够通过识别相绑定的任务配置表内的任务信息，以构建对应于任务配置表的任务实例；

任务调度单元3能够分发构建完成的任务实例，当任意一个任务实例被分发之后，对应于任务实例的任务配置表修改为已调度状态。

中间件4，用于缓存任务调度单元3分发的任务实例；当任意一个任务实例被分发之后，对应于任务实例的任务配置表修改为已调度状态。

处理集群，包括至少两个能够独立工作的处理单元5；处理单元5用于从中间件4领取并处理任务实例，其中处理单元处理自身领取的任务实例时，能够根据自身领取的任务实例的处理状态，修改任务实例对应的任务执行状态表。

任务管理模块6，用于获取任务配置表的信息和任务执行状态表的信息，监控各个任务的调度进程和处理进程，并通过可视化的方式展现给用户。

实时告警模块7，用于监控各个任务调度单元3的工作状态，在任意一个任务调度单元3工作异常时，实时告警模块7可及时向用户的邮箱发送任务告警邮件，通知相关负责人及时查看和处理。

实施例三：

在一个实施例中，提供了一种智能终端，其包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中存储器存储训练模型中的训练数据、算法公式以及滤波机制等。处理器用于提供计算和控制能力，处理器执行计算机程序时实现以下步骤：

S011、任务配置平台实时获取任务模板。

S027、任务调度单元识别绑定的任务配置表内的任务信息。

S029、任务调度单元根据获取的任务信息，在数据库中生成任务执行状态表。

S032、处理集群的各个处理单元从中间件中领取任务项目。

S033、处理单元处理自身领取的任务项目。

S034、处理单元根据任务项目的处理状态，实时修改任务实例对应的任务执行状态表。

实施例四：

在一个实施例中，提供了一种计算机可读存储介质，其存储有能够被处理器加载并执行上述超大规模任务调度分发处理方法的计算机程序，计算机程序被处理器执行时实现以下步骤：

S011、任务配置平台实时获取任务模板。

S027、任务调度单元识别绑定的任务配置表内的任务信息。

S032、处理集群的各个处理单元从中间件中领取任务项目。

S033、处理单元处理自身领取的任务项目。

所述计算机可读存储介质例如包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

具体实施方式的实施例均为本申请的较佳实施例，并非依此限制本申请的保护范围，故：凡依本申请的结构、形状、原理所做的等效变化，均应涵盖于本申请的保护范围之内。

Claims

1.一种超大规模任务调度分发处理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，还包括：

处理单元处理自身领取的任务项目。

3.根据权利要求1或2任意一项所述的方法，其特征在于，所述分发任务实例的具体方法为：

4.根据权利要求1至3任意一项所述的方法，其特征在于，还包括：

在数据库中生成对应于任务配置表的任务执行状态表；

5.根据权利要求2所述的方法，其特征在于：

所述任务实例内的各个任务项目之间能够具有依赖关系；

6.根据权利要求1所述的方法，其特征在于：

所述任务调度单元包括有等待任务配置表的空闲状态和正在识别任务配置表的忙碌状态；

7.根据权利要求4所述的方法，其特征在于，还包括：

根据各个任务执行状态表，通过可视化的方式显示对应的各个任务实例的处理状态；

8.一种超大规模任务调度分发处理方法，其特征在于，包括：

9.一种超大规模任务调度分发处理系统，其特征在于，包括：

数据库（2），用于储存各个任务配置表；其中，所述任务配置表的状态包括未调度状态、占用状态和已调度状态；

调度集群，包括至少两个能够独立工作的任务调度单元（3）；

所述任务调度单元（3）能够从数据库（2）中获取处于未调度状态的任务配置表，且当任意一个任务调度单元（3）获取了其中一个任务配置表之后，任务配置表被修改为与对应任务调度单元（3）相绑定的占用状态；

所述任务调度单元（3）能够通过识别相绑定的任务配置表内的任务信息，以构建对应于任务配置表的任务实例；

所述任务调度单元（3）能够分发构建完成的任务实例，当任意一个任务实例被分发之后，对应于任务实例的任务配置表修改为已调度状态。

10.一种计算机可读存储介质，其特征在于，存储有能够被处理器加载并执行如权利要求1至8中任一种方法的计算机程序。