分布式任务调度系统及方法

技术领域

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

背景技术

在现代互联网应用中，尤其是在分布式系统中，任务调度系统起着至关重要的作用。目前市场上的任务调度系统主要分为中心化任务调度系统和去中心化任务调度系统两类。现有的中心化任务调度系统可能存在着的单点故障、可扩展性差、性能瓶颈及调度延迟等的缺陷。现有的去中心化调度系统往往部署、配置相对复杂，学习成本较高，定制化开发较为困难，不太适合满足特定业务场景的需求。

发明内容

有鉴于此，本发明实施例提供一种分布式任务调度系统及方法，以在低成本的情况下进行快速部署和维护，增强系统的稳定性和处理效率，同时满足特定场景下对于任务状态的查看、失败任务的重试及统计分析的需求，增强用户的使用体验。

第一方面，本发明实时例提供了一种分布式任务调度系统，所述系统包括：

数据库，用于持久化存储任务队列，所述任务队列包括至少一个任务，所述任务包括任务信息，所述任务信息包括任务类型及任务状态信息；

多个任务调度单元，用于管理所述任务队列，将所述任务队列中待处理的任务下发至对应的任务处理单元，各所述任务调度单元分别管理同一类任务或不同类任务；

多个任务处理单元，用于接收所述任务调度单元下发的任务，对所述任务进行分步处理及状态监控，更新所述任务的任务状态信息。

可选地，所述系统还包括任务接收单元，用于接收待处理任务，并将所述待处理任务发送至所述数据库以形成所述任务队列。

可选地，所述任务调度单元进一步被配置为响应于所述待处理任务的任务类型满足预定条件，基于调度策略将所述待处理的任务下发至对应的任务处理单元。

可选地，所述任务处理单元进一步被配置为根据所述任务的任务类型将所述任务分解为至少一个分步子任务，根据各所述分步子任务的依赖关系将各所述分步子任务发送至所述任务处理单元中对应的处理节点进行处理。

可选地，所述任务处理单元进一步被配置为对处理失败的分步子任务进行重试处理，响应于重试次数超过预定阈值，停止对当前任务的分步处理。

可选地，所述任务处理单元进一步被配置为对各处理节点的分步子任务的处理状态进行监控，根据所述处理状态更新数据库中对应的任务状态信息，所述任务状态信息包括待处理、处理进度和处理结果中的一种或多种。

可选地，所述任务调度单元还用于监控所述任务队列中各任务的任务状态信息，对处理失败的任务进行邮件报警。

可选地，管理同一类任务的多个任务调度单元形成对应类型的任务管理集群；处理同一类任务的多个任务处理单元形成对应类型的任务处理集群。

可选地，所述多个任务调度单元基于竞争机制对所述待处理任务进行调度。

第二方面，本发明实施例提供了一种分布式任务调度方法，所述方法包括：

根据任务队列中的待处理任务的任务类型确定目标任务调度单元，所述任务队列包括至少一个待处理任务，所述待处理任务的信息包括任务类型及任务状态信息；

通过所述目标任务调度单元将所述待处理任务下发至对应的目标任务处理单元；

通过所述目标任务处理单元对所述待处理任务进行分步处理和状态监控，以更新所述待处理任务的任务状态信息；

其中，所述分步处理的步骤具体包括：

根据所述待处理任务的任务类型将所述待处理任务分解为至少一个分步子任务；

根据各所述分步子任务的依赖关系将各所述分步子任务发送至所述任务处理单元中对应的处理节点进行处理。

本发明实施例不需要额外的服务器和中心控制机构，实现在低成本的情况下进行快速部署和维护。以异步任务的形式对任务进行分步处理，缩短了任务处理时间，同时减少了用户的等待时间。通过设置多个任务调度及处理单元的冗余，提高了系统的稳定性和处理效率。设置持久化存储的任务队列和任务状态更新机制，以满足某些场景下对任务状态的查看、失败任务的重试以及统计分析等的工作需求，为用户带来更加便捷的使用体验。

附图说明

通过以下参照附图对本发明实施例的描述，本发明的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1是本发明实施例的分布式任务调度系统的结构示意图；

图2是本发明实施例的一种任务队列的存储形式示意图；

图3是本发明实施例的另一种任务队列的存储形式示意图；

图4是本发明实施例的一种任务调度方法的流程图；

图5是本发明实施例的分布式任务调度处理方法的流程图；

图6是本发明实施例的一种具体应用场景下的任务调度处理流程图；

图7是本发明实施例的分布式任务调度处理装置的示意图。

具体实施方式

以下基于实施例对本申请进行描述，但是本申请并不仅仅限于这些实施例。在下文对本申请的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本申请。为了避免混淆本申请的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。

此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。

除非上下文明确要求，否则整个申请文件中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在一些应用软件开发中，会有一些执行时间较长的任务，例如常见的下载任务、提取任务和生成任务等。如果将这些任务放在前端执行，会增加用户的等待时间，带来不好的使用体验。由此，异步任务应运而生，异步任务是相对于同步任务而言的，同步任务是指进入主线程排队、直接被主线程执行的任务，其具有阻塞效果，只有前一个任务执行完毕，才能执行后一个任务。相反，异步任务是指不进入主线程、而进入任务队列的任务，其在执行过程中采用回调函数的形式被执行。在软件开发时，可以将任务放在后台处理，待用户需要查看结果时，点击查看即可，并且可以随时看到任务执行状态。

本发明实施例的任务调度系统是将用户提交的任务预先存储在任务队列中，以异步任务的形式进行调度处理，在具有空闲线程时，对任务队列中的任务进行分步处理，可以缩短任务的处理时间，减少用户的等待时间。本发明实施例涉及到的任务主要为耗时较长的任务，例如音视频下载、文案提取、生成图片和生成文字等，应理解，本实施例的任务调度系统不限于处理上述耗时任务，任意存储在任务队列中的任务的处理均可应用本实施例的任务调度系统，本实施例不对此进行限制。

图1是本发明实施例分布式任务调度系统的结构示意图。如图1所示，该分布式任务调度系统包括：数据库10、多个任务调度单元11和多个任务处理单元12。

示例地，如图1所示的任务调度系统，多个任务调度单元11包括任务调度单元1-n(n大于1)，每个任务调度单元11下关联着若干个任务处理单元12，例如：

任务调度单元1下关联着任务处理单元1-1至任务处理单元1-i(i大于1)。

任务调度单元2下关联着任务处理单元2-1至任务处理单元2-j(j大于1)。

任务调度单元n下关联着任务处理单元n-1至任务处理单元n-k(k大于1)。

可选地，任务调度单元1-n可以对应着同一类型的任务，也可以对应着多种类型的任务。

在另一种可选的实现方式中，一种类型的任务对应着多个任务调度单元11和多个任务处理单元12，其中，每个任务调度单元11都关联着处理该类任务的全部任务处理单元12。例如，若图1中的任务调度单元1和2对应着同种类型的任务，如文案提取任务，系统中预设了5个处理文案提取任务的任务处理单元，则任务调度单元1和2分别与这5个任务处理单元相关联，即任务调度单元1和任务调度单元2都能对这5个任务处理单元进行任务调度以处理文案提取任务。由此，可以使得在管理某一类型任务的任务调度单元故障时，其他管理同类型任务的任务调度单元依旧可以对处理该类任务的任务处理单元进行任务调度，提高任务处理单元的利用率，进而可以提高任务处理效率。

可选地，上述数据库10、多个任务调度单元11和多个任务处理单元12可以部署在同一台计算机设备上，也可以分别部署在不同的计算机设备上。

可选地，数据库10可以为MySQL(Relational Database Management System，关系数据库管理系统)、Redis(Remote Dictionary Server，远程字典服务)、MongoDB(MongoDatabase，一种基于分布式文件存储的数据库)等类型的数据库。一个任务调度单元11可以为一个独立的任务调度的中间组件，一个任务处理单元12可以为一个独立的任务处理进程。

数据库10用于持久化存储任务队列及任务信息。其中，任务队列包括至少一个任务，任务信息至少包括任务类型及任务状态信息。多个任务调度单元11用于监听任务队列，分别对同一类或不同类的待处理的任务进行调度，更新任务状态信息。任务处理单元12用于接收任务调度单元11下发的任务，对任务进行分步处理，更新任务状态信息。

在一种可选的实现方式中，所述系统还包括任务接收单元，任务接收单元在接收到用户提交的待处理任务时，会首先判断待处理的任务是否可以作为异步任务进行处理(例如根据待处理任务的任务性质或紧急程度)，将可以以异步任务形式进行处理的待处理任务发送至数据库10中。

可选的，数据库10中可以存储有一个任务队列，以存放一种类型或多种类型的任务。也可以存储有多个任务队列，分别用来存放不同类型的任务。

图2是本发明实施例的一种任务队列的存储形式示意图。如图2所示，数据库10中包括一个任务队列，其中包括A、B、C三种类型的任务，其中，每一个任务(例如任务A1)中都包括该任务对应的任务信息。

图3是本发明实施例的另一种任务队列的存储形式示意图。如图3所示，数据库10中包括三个任务队列，分别对应存放着三种不同类型的任务，同样，每一个任务(例如任务A1)中都包括该任务对应的任务信息。容易理解地，本实施例中数据库10中任务队列的数量根据系统处理的任务类型有关，若系统仅处理一种类型的任务时，数据库10种包括一个任务队列，其中存放在一种类型的任务。

本实施例将任务队列持久化存储在数据库10中，以便于后续任务状态的查询、失败任务的重试、以及统计分析等的工作。同时，当系统中的某一个单元宕机或者系统故障时，系统可以根据保存的任务队列状态来恢复之前未处理完成的任务，保证任务不会因为系统故障而丢失。

多个任务调度单元11用于管理任务队列，将所述任务队列中待处理的任务下发至对应的任务处理单元12，各所述任务调度单元11管理同一类任务或不同类任务。

任务调度单元11的数量根据应用程序的需求自行设置，对于同一类型的任务，对应的多个任务调度单元11形成任务管理调度集群，以提高系统的高可用性，同时，当某个任务调度单元11出现故障时，其他任务调度单元11仍能正常工作。另外，可以通过增加更多的任务调度单元来扩展系统的处理能力，提高系统的可扩展性。

可选地，根据数据库10中的任务队列的存储形式不同，对应的任务调度单元11的类型与监听对象也不同。例如，若数据库10中包括一个任务队列，其中包括一种类型的任务，则任务调度单元1-n为同种类型，监听同一任务队列，对同一类任务进行调度。若数据库10中包括一个任务队列，其中包括三种类型的任务，则任务调度单元1-n中包括三种类型的任务调度单元，监听同一个任务队列，判断待处理任务的任务类型后，对满足预定条件的待处理任务(即待处理任务的任务类型与自身类型相匹配)进行调度。若数据库中包括三个任务队列，分别存放着三种不同类型的任务，则任务调度单元1-n中包括三种不同类型的任务调度单元，分别监听对应类型的任务队列，对其中的待处理任务进行调度。

图4是本发明实施例的一种任务调度方法的流程图。图4所示的任务调度流程为一个任务调度单元11的调度流程，如图4所示，具体的任务调度步骤如下：

步骤S401，监听任务队列。

任务调度系统中的每个任务调度单元11均是通过监听的方式，监听任务队列中是否存在待处理的任务，当监听到存在待处理的任务、且该任务的任务类型满足预定条件时(即待处理任务的任务类型与自身设置的所管理的任务相匹配)，则获取该待处理的任务并基于调度策略将该任务下发至对应的处理单元。

在一种可选的实现方式中，每个任务调度单元11可以设置为以预定的时间间隔定期访问数据库，监听数据库中任务队列中是否存在待处理的任务。

在一种可选的实现方式中，可以设置分布式锁的竞争机制以保证任务队列中的一个异步任务只被一个任务调度单元调度一次。即在同一时间，一个异步任务队列只允许一个任务调度单元进行访问，其他任务调度单元不允许访问。例如，当任务调度单元1在预某一时刻访问一个任务队列时，若存在任务调度单元2正在访问该任务队列，那么任务调度单元1本次将不能访问该任务队列。

在一种可选的实现方式中，进入任务队列的任务的初始任务状态信息为待处理，随着任务处理进度的推进，数据库中的任务状态信息会进行相应的更新。任务调度单元11可以对各任务的任务状态信息进行监听，以判断任务队列中是否有对应类型的待处理的任务。

步骤S402，判断任务队列中是否有对应类型的待处理的任务。若是，跳转到步骤S403；若否，跳转到步骤S401。

步骤S403，根据调度策略确定目标任务处理单元。

可选地，所述调度策略为负载均衡策略或随机策略等。具体地，本实施例中的负载均衡策略是指多个任务处理单元提供相同的任务处理服务时，任务调度单元11根据预定方法对任务进行调度使得各个任务处理单元12的任务处理量达到均衡。常用的负载均衡方法包括：轮询法、加权轮询法、最小连接数法、最快响应法和Hash法。

本实施例中的随机策略指任务调度单元随机选择其下空闲的任务处理单元12进行任务调度。

根据监听到的待处理任务的数量不同，通过上述或其他调度策略确定一个或多个目标任务处理单元12来进行任务调度。

步骤S404，将对应类型的待处理的任务下发至目标任务处理单元。

步骤S405，更新对应任务的任务状态信息。

可选地，每个任务调度单元11也都对应的任务状态信息的更新功能，当一个待处理的任务被某一个任务调度单元11分发至对应的任务处理单元12后，该任务调度单元会将存储在数据库中的相应任务的任务状态信息更新为处理中。因为每一个任务调度单元11都是对任务队列中的待处理的任务进行调度，如此可以避免了一个任务被重复调度。

在一种可选的实现方式中，任务调度单元11在对任务队列进行监听时，除了上述对待处理的任务进行监听外，还可以监听已处理任务的任务状态信息，响应于监测到处理失败的异步任务，发送邮件至指定邮箱进行邮件报警，以使得维护人员可以及时了解系统的运行状态和快速进行故障处理。

多个任务处理单元12用于接收所述任务调度单元下发的任务，对所述任务进行分步处理及状态监控，更新所述任务的任务状态信息。

在对任务进行分步处理时，不同类型的任务对应着不同的处理步骤，可以根据任务类型的不同将一个任务分解为至少一个分步子任务，各个分步子任务间存在依赖关系。

在本发明实施例中，依赖关系指的是各个子任务间的相互关系，各子任务的依赖关系分为完成-开始型，即只有在子任务A完成后，子任务B才能开始；开始-开始型，指的是子任务A和子任务B同时开始；完成-完成型，即只有完成了子任务A，子任务B才能结束。

例如一个文案提取任务可以分解为下载音频和文案提取两个子任务，在下载音频结束后才能进行文案提取，因此音频下载和文案提取两个子任务间的依赖关系为完成-开始型。

可以理解地，本发明实施例的分步子任务的依赖关系可以为上述三种依赖关系的一种或多种，具体根据任务的任务类型及处理步骤进行设置。

在一种可选的实现方式中，一个任务的分解信息及子任务间的依赖关系可以存储在每个任务对应的任务信息中。在另一种可选的实现方式中，同一类型任务具有相同的处理步骤，为了节约存储资源，可以将所述分解信息和子任务间的依赖关系配置在各个对应类型的任务处理单元12中。

在一种可选的实现方式中，任务处理单元12下包括一个或多个任务处理节点，以分别处理不同的分步子任务。任务处理单元12根据任务的任务类型将所述任务分解为至少一个分步子任务，根据各所述分步子任务的依赖关系将各所述分步子任务发送至所述任务处理单元中对应的处理节点进行处理。

进一步地，任务处理单元12对各处理节点的分步子任务的处理状态进行监控，根据所述处理状态更新数据库中对应任务的任务状态信息。可选地，任务队列中各任务的任务状态信息包括待处理、处理进度和处理结果等的一种或多种。

可选地，任务处理单元12下的各个任务处理节点会提供任务详情的查询接口以供任务处理单元12对各处理节点的任务处理状态进行监控。可选地，任务处理单元12可以以预定的时间周期通过任务详情的查询接口获取各个任务处理节点的处理状态。

在一种可选的实现方式中，任务处理单元12可以对监听到的处理失败的分步子任务进行重试处理，当重试次数超过预定阈值时，停止对当前任务的分步处理，并更新当前任务的任务状态为处理失败。

可选地，可以预先指定每一个分步子任务的重试次数，当一个分步子任务处理失败后重新提交当前的分步子任务至对应的任务处理节点进行重试，直到重试次数超过指定的重试次数。

可选地，在对处理失败的任务进行任务状态更新时，可以根据实际需求自定义配置进行错误描述，记录失败原因或错误代码等。

本实施例通过对失败任务的自动重试处理，可以提高系统的容错性能，增强系统的可靠性，提高用户的使用体验。

由此，本发明实施例中包括数据库10，多个任务调度单元11作为任务调度的中间组件，多个任务处理单元12进行任务的分步处理，不需要额外的服务器和中心控制机构，实现在低成本的情况下进行快速部署和维护。以异步任务的形式对用户提交的任务进行处理，在系统具有空闲进程时，对任务队列中的任务进行分步处理，缩短了任务处理时间，同时也减少了用户的等待时间。通过设置多个任务调度及处理单元的冗余，提高了系统的稳定性和处理效率。设置持久化存储的任务队列和任务状态更新机制，以满足某些场景下对任务状态的查看、失败任务的重试以及统计分析等的工作需求，为用户带来更加便捷的使用体验。

图5是本发明实施例的分布式任务调度处理方法的流程图。优选地，该分布式任务调度方法适用于上述实施例1的分布式任务调度系统，当然，本领域技术人员能够知晓的是，该任务调度方法也可以应用于其他形式的系统或设备中，本发明不限定该分布式任务调度处理方法的应用场景。在本实施例的任务调度处理方法中，预先将用户提交的任务存储在预定的任务队列中，如图5所示，该任务调度方法包括以下步骤：

步骤S100，根据任务队列中的待处理任务的任务类型确定目标任务调度单元。

其中，任务队列中包括至少一个待处理任务，所述待处理任务包括任务信息，所述任务信息至少包括任务类型及任务状态信息，任务状态信息可以根据任务处理过程中的处理进度而进行更新。

在一种可选的实现方式中，预先将用户提交的任务存储在数据库中的任务队列中，以异步任务的形式对用户提交的任务进行处理。可选地，用户提交的任务可以以批量的形式进入任务队列，也可以以单个任务的形式进入任务队列。

可选地，应用本实施例任务调度方法的任务调度系统中包括多种类型的任务调度单元，以分别管理不同类型的任务，因此首先要根据待处理任务的任务类型确定目标任务调度单元。

在一种可选的实现方式中，系统中一种类型的任务调度单元包括多个以形成冗余，根据任务类型确定对应类型的多个任务调度单元后，可以进一步根据预定规则(例如上述分布式锁机制)从多个任务调度单元中确定一个任务调度单元作为目标任务调度单元，以保证待处理任务不会被其他任务调度单元重复调用。

可选的，目标调度单元一次可对一个或多个待处理任务进行调度。

步骤S200，通过所述目标调度单元将所述待处理任务下发至对应的目标任务处理单元。

可选地，目标任务调度单元下关联着多个任务处理单元，根据多个任务处理单元的资源占用情况或调度策略(例如上述的负载均衡策略或随机策略)确定一个或多个目标任务处理单元，以将一个或多个待处理任务下发至一个或多个目标任务处理单元。

步骤S300，通过所述目标任务处理单元对所述待处理任务进行分步处理和状态监控，以更新所述待处理任务的任务状态信息。

在一种可选的实现方式中，任务处理单元中预先存储着处理对应任务类型的任务的分步处理步骤，可选的，每个任务处理单元下包括若干个任务处理节点。可选地，上述分步处理的步骤具体包括任务分解和子任务。

具体地，任务分解具体可以为根据所述待处理任务的任务类型将所述待处理任务分解为至少一个分步子任务。

本实施例中的同一类任务具有相同的处理步骤，因此，不同类型的任务处理单元在对不同类型的任务进行处理时，根据任务类型将当前处理的任务分解为一个或多个分步子任务，其中，各个分步子任务间具有依赖关系。

具体地，子任务分发具体可以为根据各所述分步子任务的依赖关系将各所述分步子任务发送至所述任务处理单元中对应的处理节点进行处理。

可选地，分步子任务间的依赖关系为完成-开始型、开始-开始型和完成-完成型中的一种或多种，任务处理单元根据各个分步子任务的依赖关系将各分步子任务发送至其下对应的任务处理节点进行顺序或并行处理。

在一种可选的实现方式中，任务处理单元中的各任务处理节点会提供任务详情的查询接口以供任务处理单元对各处理节点的子任务处理状态进行监控。可选地，任务处理单元可以以预定的时间周期通过任务详情的查询接口获取各个任务处理节点的处理状态。

在一种可选的实现方式中，通过预设重试次数阈值，任务处理单元可以将监控到的处理失败的分步子任务重新发送至对应的任务处理节点进行重试，响应于重试次数超过预设阈值，将当前的分步子任务的任务状态更新为处理失败，并停止对当前整个任务的处理。

进一步地，任务处理单元根据各个任务处理节点的分步子任务处理进度对数据库中的对应任务的任务状态信息进行更新，以方便用户对任务处理状态的查询。

本发明实施例预先将用户提交的任务存储在任务队列中，在系统具有空闲进程时，对异步任务队列中的任务进行分步处理，缩短了任务处理时间，同时也减少了用户的等待时间。任务调度单元根据各个任务处理单元的占用情况对待处理任务进行调用，提高了任务处理过程中的资源分配效率。任务处理单元对异步任务进行分步处理，增强了系统的处理效率。设置持久化存储的异步任务队列任务状态更新机制，以满足某些场景下对任务状态的查看、失败任务的重试以及统计分析等的工作需求，为用户带来更加便捷的使用体验。

为了便于理解，下面以文案提取的这一具体类型的任务为例对本方案的异步任务处理方法进行说明。

图6是本发明实施例的一种具体应用场景下的任务调度处理流程图。图6所示的异步任务调度处理流程应用于文案提取任务，本发明实施例预先将用户提交的文案提取任务存储在预定的任务队列中，任务队列中还包括各个文案提取任务的任务状态信息。如图6所示，文案提取任务的调度处理流程如下：

步骤S601，任务调度。

在一种可选的实现方式中，系统中包括多个负责管理文案提取任务的任务调度单元，多个任务调度单元根据预定规则(例如上述分布式锁机制)监听同一任务队列，以保证同一时刻同一任务队列仅被一个任务调度单元监听。

可选地，任务队列中各任务的任务状态信息的初始状态为待处理，任务状态信息会根据任务的处理进度进行更新。在某一时刻，某一处理文案提取任务的任务调度单元对任务队列进行监听时，若监听到任务队列中存在待处理的文案提取任务，该任务调度单元根据调度策略将待处理的文案提取任务下发至对应的任务处理单元，其中，监听到的待处理任务为一个或多个。

可选的，任务调度单元在对监听到的一个或多个待处理的文案提取任务进行调度时，根据待处理的文案提取任务的数量、关联的任务处理单元的处理能力、资源占用情况等，将一个或多个待处理任务下发至一个或多个任务处理单元。

在一种可选的实现方式中，任务调度单元在对待处理的文案提取任务进行调度后，会将数据库中对应的文案提取任务的任务状态更新为处理中。

如此，根据各个任务处理单元的空闲程度，利用任务处理单元对任务队列中的文案提取任务进行调度，可以提高系统的资源利用效率。

步骤S602，提交下载任务。

在本发明实施例中，任务处理单元将某一个文案提取任务下发至某个处理文案提取的任务处理单元中，任务处理单元会根据预设的处理规则对该文案提取任务进行处理。

在本发明实施例中，一个文案提取任务会被分解为一个下载任务和一个文案提取任务，且两个任务的依赖关系为完成-开始型，即下载任务成功完成后，才能进行文案提取任务。

任务处理单元首先将下载任务提交至任务处理单元下对应的任务下载节点，在任务下载节点中处理下载任务。

步骤S603，监听下载进度。同时进行步骤S604。若下载成功，跳转至步骤S606，若下载失败，跳转至步骤S605。

在一种可选的实现方式中，任务处理单元将下载任务提交至对应的任务下载节点后，会对任务下载节点中的下载进度进行监听。

在一种可选的实现方式中，任务下载节点会提供下载任务的任务详情查询接口以供任务处理单元进行任务进度的监听，任务处理单元会以预定的时间周期通过任务处理节点提供的任务详情查询接口监听该处理节点中下载任务的处理进度。

步骤S604，更新下载进度。

任务处理单元根据监听到底下载进度更新任务队列中对应的文案提取任务的任务状态信息。

步骤S605，判断是否超出重试次数。若是，跳转至步骤S610，若否，跳转至步骤S602。

在一种可选的实现方式中，任务处理单元还支持对处理失败的下载任务的重试处理。可选地，可以设置预定的重试次数阈值，根据当前下载任务的重试次数判断是否继续处理当前文案提取任务，若重试次数超过预定阈值，停止对当前文案提取任务的处理，即结束当前的整个文案提取任务。

步骤S606，提交文案提取任务。

响应于下载任务处理成功，任务处理单元将文案提取任务下发至对应的处理文案提取任务处理节点。

步骤S607，监听文案提取进度。

同样地，处理文案提取子任务的文案提取的任务处理节点会提供文案提取的任务详情查询接口，以供任务处理单元对文案提取的处理进度进行监听任务处理单元对文案提取任务的提取进度进行监听，同时进入步骤S608，根据监听到的任务提取进度更新任务队列中对应的文案提取任务的状态信息。若提取成功，跳转至步骤S610，若提取失败，跳转至步骤S609。

步骤S608，更新文案提取进度。

同样地，任务处理单元根据监听到文案提取任务的处理进度更新任务队列中对应的文案提取任务的任务状态信息。

步骤S609，判断是否超出重试次数。若是，跳转到步骤S610。若否，跳转到步骤S606。

可选地，对处理失败的文案提取子任务进行重试处理，响应于重试次数超过预定阈值，停止对当前的文案提取任务的执行，即整个文案提取任务结束。

步骤S610，文案提取任务结束。

本发明实施例预先将用户提交的文案提取任务存储在任务队列中，在系统具有空闲进程时，对任务队列中的文案提取任务进行分步处理，缩短了任务处理时间，同时也减少了用户的等待时间。利用任务调度单元根据各个任务处理单元的占用情况对任务进行调度，提高了任务处理过程中的资源分配效率。通过任务处理单元对任务进行分步处理，增强了系统的处理效率。设置任务状态更新机制，以满足某些场景下对任务状态的查看、统计分析等的工作需求，为用户带来更加便捷的使用体验。

图7是本发明实施例的分布式任务调度处理装置示意图。如图7所示，本发明实施例的分布式任务调度处理装置包括第一确定单元70、任务分发单元71和任务执行单元72。

其中，第一确定单元70用于根据任务队列中的待处理任务的任务类型确定目标调度单元，所述任务队列包括至少一个待处理任务，所述待处理任务的任务信息包括任务类型及任务状态信息。

任务分发单元71用于通过所述目标任务调度单元将所述待处理任务下发至对应的目标任务处理单元。

任务执行单元72用于通过所述目标任务处理单元对所述待处理任务进行分步处理和状态监控，以更新所述待处理任务的任务状态信息。

进一步地，所述任务执行单元72包括任务分解单元、子任务执行单元和状态监控单元。

其中，任务分解单元用于根据所述待处理任务的任务类型将所述待处理任务分解为至少一个分步子任务。子任务执行单元用于根据各所述分步子任务的依赖关系将各所述分步子任务发送至所述任务处理单元中对应的处理节点进行处理。状态监控单元用于对各处理节点的子任务的处理进度进行状态监控，并根据监控到的子任务处理状态跟新数据库中对应任务的任务状态信息。

本发明实施例预先将用户提交的任务存储在任务队列中，在系统具有空闲进程时，对任务队列中的文案提取任务进行分步处理，缩短了任务处理时间，同时也减少了用户的等待时间。利用任务调度单元确定目标任务处理单元对任务进行调度分发，提高了任务处理过程中的资源分配效率。通过任务处理单元对任务进行分步处理，增强了系统的处理效率。设置任务状态更新机制，以满足某些场景下对任务状态的查看、统计分析等的工作需求，为用户带来更加便捷的使用体验。

本领域的技术人员应明白，本申请的实施例可提供为方法、装置(设备)或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品。

本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图来描述的。应理解可由计算机程序指令实现流程图中的每一流程。

这些计算机程序指令可以存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现流程图一个流程或多个流程中指定的功能。

也可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程中指定的功能的装置。

本发明的另一实施例涉及一种非易失性存储介质，用于存储计算机可读程序，所述计算机可读程序用于供计算机执行上述部分或全部的方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指定相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域技术人员而言，本申请可以有各种改动和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。