CN112231073A - 一种分布式任务调度方法及其装置 - Google Patents

Abstract

本申请公开了一种分布式任务调度方法及其装置。本申请中，第一服务的客户端根据为所述第一服务配置的任务配置信息，确定需要获取的任务的种类，并根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务并异步执行。其中，所述任务配置信息包括所述第一服务包含的任务种类信息；与所述种类对应的任务队列用于存储所述种类的任务。

Description

一种分布式任务调度方法及其装置

技术领域

本申请涉及任务处理技术，尤其涉及一种分布式任务调度方法及其装置。

背景技术

在网站后台服务中，经常会遇到批量执行异步任务的需求，任务提交方提交任务后，继续执行自己的业务，待任务执行完成或异常时再执行相应的逻辑。

如果采用单机服务器进行任务调度，则受限于单机服务器的资源限制，任务调度和任务执行的效率较低。

因此，考虑到系统可用性，对于需要进行异步执行任务的服务，需要具备分布式任务调度能力。

发明内容

本申请实施例提供一种分布式任务调度方法及其装置。

第一方面，提供一种分布式任务调度方法，包括：

第一服务的客户端根据为所述第一服务配置的任务配置信息，确定需要获取的任务的种类，并根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务并异步执行。其中，所述任务配置信息包括所述第一服务包含的任务种类信息，所述第一服务的客户端；其中，与所述种类对应的任务队列用于存储所述种类的任务。

在一种可能的实现方式中，所述需要获取的任务的种类至少为一种；所述第一服务的客户端根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务，包括：

所述第一服务的客户端依次针对所述至少一种任务中的每种任务，执行以下步骤，直到满足结束条件为止：

针对当前任务种类，确定所述第一服务的客户端上执行的该种任务的数量是否小于该种任务对应的单机并发数量门限，若是，则从该种任务对应的任务队列中获取一个任务，否则，获取下一个任务种类作为当前任务种类。

可选地，所述结束条件包括：所述第一服务的客户端当前执行的所述至少一种任务中的每种任务的数量等于对应任务种类的单机并发数量门限；或者，所述第一服务的客户端当前执行的所述至少一种任务中，一部分任务种类中的每种任务的数量等于对应任务种类的单机并发数量门限，其余部分任务种类中的每种任务对应的任务队列为空。

在一种可能的实现方式中，所述从所述种类对应的任务队列中取出任务并异步执行，包括：所述第一服务的客户端从所述种类对应的任务队列中取出任务后并在执行该任务之前，根据所述种类对应的任务有效时间，判断被取出的任务从取出到当前的时间长度是否小于所述任务有效时间，若是，则执行所述被取出的任务。

在一种可能的实现方式中，还包括：所述第一服务的客户端根据为当前执行的任务所属的任务种类配置的任务执行时间，判断所述当前执行的任务的执行时间长度是否大于或等于所述任务执行时间，若是，则结束执行所述当前执行的任务。

在一种可能的实现方式中，还包括：若任务执行成功，则记录任务执行成功的日志，发送任务执行成功的通知；若任务执行失败，则记录任务执行失败的日志，发送任务执行失败的通知。

在一种可能的实现方式中，还包括：第一服务的客户端生成任务后，根据生成的任务所属的任务种类，将生成的任务提交到该任务种类对应的任务队列。

在一种可能的实现方式中，为所述第一服务配置的任务配置信息，还包括：为所述第一服务包含的至少一个任务种类配置的与相应任务种类对应的任务有效时间，所述任务有效时间用于在执行被取出的相应种类的任务前判决该任务是否有效；和/或，为所述第一服务包含的至少一个任务种类配置的与相应任务种类对应的任务执行时间，所述任务执行时间用于判决相应种类的任务的执行时间是否超时。

第二方面，提供一种分布式任务调度装置，包括：

任务获取模块，用于根据为所述第一服务配置的任务配置信息，确定需要获取的任务的种类；其中，所述任务配置信息包括所述第一服务包含的任务种类信息；以及，根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务；其中，与所述种类对应的任务队列用于存储所述种类的任务；

任务执行模块，用于异步执行所述任务获取模块从任务队列取出的任务。

可选地，还包括：任务提交模块，用于生成任务后，根据生成的任务所属的任务种类，将生成的任务提交到该任务种类对应的任务队列。

第三方面，提供一种分布式任务调度装置，包括：处理器、存储器；所述处理器，用于读取所述存储器中的计算机指令，执行如上述第一方面中任一项所述的方法。

第四方面，提供一种计算机存储介质，所述计算机存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行如上述第一方面中任一项所述的方法。

本申请的实施例中，一个服务的客户端在进行任务调度时，根据为该服务配置的任务配置信息，确定需要获取的任务的种类，然后根据所述需要获取的任务的种类，确定本客户端当前执行的与该种类的任务的数量小于该种类对应的单机并发数量门限，则从该种类对应的任务队列中取出任务并异步执行。可以看出，一方面，由于本申请的上述实施例采用了任务队列，实现了分布式任务调度；另一方面，由于不同任务种类对应不同的任务队列，并且在进行任务调度时可通过任务种类对应的单机并发数量门限控制客户端上同一种类的任务的数量，从而实现了同种任务的批量顺序处理；再一方面，本申请上述实施例基于客户端模式实现，使得整个任务调度流程更轻量级，并且不需要额外部署任务调度服务器。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示例性示出了本申请实施例中任务提交原理框架图；

图2示例性示出了本申请实施例中任务拉取原理框架图；

图3示例性示出了本申请实施例中任务拉取的通用流程图；

图4示例性示出了本申请实施例中客户端1和客户端2执行的任务拉取流程示意图；

图5示例性示出了本申请实施例中客户端3执行的任务拉取流程示意图；

图6示例性示出了本申请实施例中分布式任务调度装置的结构示意图；

图7示例性示出了本申请实施例中分布式任务调度设备的结构示意图。

具体实施方式

下面首先结合附图对本申请所涉及的概念进行说明。在此需要指出的是，以下对各个概念的说明，仅为了使本申请的内容更加容易理解，并不表示对本申请保护范围的限定。

应当理解，本申请中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，例如能够根据本申请实施例图示或描述中给出那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

本申请中使用的术语“模块”“服务”，是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件和/或软件代码的组合，能够执行与该元件相关的功能。

目前，业界已经实现使用JDK(Java Development Kit)提供的线程池框架提交任务。JDK是Java语言的软件开发工具包，其中提供了线程池框架。使用JDK提供的线程池框架提交任务，虽然支持任务队列，但所提交任务的只能在任务提交方服务所在的实例上执行，属于单机任务调度，无法满足服务具有分布式能力的要求。

为解决上述问题，业界还提供了一种支持分布式的任务调度框架Quartz。Quartz是一个由Java语言编写的开源任务调度框架，框架自身利用数据库实现了分布式调度能力。使用任务调度框架Quartz，虽然框架本身实现了分布式调度的能力，但是对于单个任务而言，只支持定时执行和实时提交，不满足同一种任务批量队列执行的功能。

为解决上述问题，本申请实施例提供了一种支持任务队列的分布式任务调度方法。本申请实施例基于客户端模式使得整个任务调度流程更轻量级，并且不需要额外部署任务调度服务器；用任务队列的方式支持同种任务的批量顺序处理；并且支持同一个服务的不同实例间共享任务队列，从而达到了任务分布式处理的效果。

本申请实施例与使用JDK的线程池框架的任务调度机制相比，增加了分布式执行任务的能力，与使用Quartz任务调度框架的任务调度机制相比，增加了任务队列执行的能力，同时又不需要部署独立的任务调度服务，兼顾了上述两种任务调度机制的优点，又改善了上述两种任务调度机制的缺点。

下面结合附图对本申请实施例进行详细描述。

本申请实施例可应用于业务系统，具体可实现对业务系统中的任务进行分布式调度。举例来说，所述业务系统可以是网站后台服务系统。

一个业务系统通常包括多个服务(service)，一个服务用于实现某种业务或某种功能。一个服务中包含至少一种任务。

本申请实施例中，一个服务可生成多个应用实例，一个应用实例在一个客户端上执行，即一个服务可以被配置在多个客户端上执行。

一个服务中包含的所有任务可由该服务的一个或多个客户端处理，一个客户端可以处理一个服务中的所有种类的任务。

本申请实施例中，可以预先为每个服务配置相应服务对应的任务配置信息。一个服务的任务配置信息主要用于描述该服务中所包含的任务种类。比如，第一服务的任务配置信息包括第一服务包含的任务种类信息，第二服务的任务配置信息包括第二服务包含的任务种类信息。

具体来说，一个服务的任务配置信息可包括该服务中包含的任务种类的描述信息，每种任务对应的任务队列的容量大小等。其中，可选地，所述任务种类的描述信息可包括任务名称，还可包括任务所属项目的项目名称。

本申请实施例中，一个服务包含一个或多个项目，一个项目包含一个或多个任务。同一任务种类对应同一任务队列。其中，相同种类的任务是指相同项目下具有相同任务名称的任务。

可选地，一个服务对应的任务配置信息还可包括为该服务所包含的至少一个任务种类所配置的任务有效时间、任务超时时间中的至少一个。具体实施时，可为一个服务中的每个任务种类分别配置任务有效时间、任务超时时间。

其中，一个任务种类对应的任务有效时间用于在执行被取出的相应种类的任务前判决该任务是否有效。具体地，客户端从任务队列中取出任务后并在执行该任务之前，可根据对应的任务有效时间，判断被取出的任务从取出到当前的时间长度是否小于该任务有效时间，若是，则判决该任务有效，否则判决该任务无效。进一步地，被判决为有效的任务可被执行，对于被判决为无效的任务可被放弃执行。通常情况下，一个任务从任务队列中取出到执行前，若等待的时间较长，则表明系统可能出现异常，采用上述方法，可以避免一个任务因等待过长时间而导致任务的时效性降低。

一个任务种类对应的任务执行时间用于判决相应种类的任务的执行是否超时。具体地，客户端根据为当前执行的任务所属的任务种类配置的任务执行时间，判断当前执行的任务的执行时间长度是否大于或等于该任务执行时间，若是，则判决该任务执行超时，否则判决该任务执行未超时。进一步地，对于被判决为执行超时的任务，可结束执行该任务，对于被判决为执行未超时的任务可以继续执行。通常，一个任务执行超时，可能是由于该任务异常所导致的，通过上述方法可以避免异常任务占用过多系统资源。

可选地，在本申请的一些实施例中，如果一个服务中包含多种任务，则可以采用多实例多任务队列，即为该服务配置多个应用实例，不同的应用实例运行在不同的客户端上，每个客户端可以处理该服务中的所有种类的任务。如果一个服务中仅包含一种任务，则可以采用单实例单任务队列，即，为该服务配置一个应用实例，该应用实例运行在一个客户端上，该客户端处理该服务中仅有的一种任务。

可选地，在本申请的一些实施例中，还可针对一个服务中的所有任务队列，指定队列配置方式。本申请实施例中，任务队列可使用中间件实现，可支持两种队列配置方式，分别为关系型数据库(Mysql)和内存数据库(Redis)。其中，Mysql是一个开源的关系型数据库管理系统，Redis是一个使用C语言编写的开源的键值数据库。关系型数据库(Mysql)队列配置方式支持持久化历史任务数据。如果不需要持久化历史任务数据，可配置为内存数据库(Redis)，以节省存储成本。如果不特别指定队列配置方式，则默认为采用关系型数据库(Mysql)队列配置方式。

本申请实施例中，以使用Java实现任务调度为例，在服务中引入用于实现任务调度的jar文件，以实现本申请实施例提供的任务调度功能。Jar文件可聚合大量的Java类文件、相关的元数据和资源，可用于发布和使用类库，作为应用程序和扩展的构建单元，或者作为组件、applet或者插件程序的部署单位。

在服务启动后的正常运行过程中，任务调度流程可分为提交(submit)任务和拉取(pull)任务。其中，提交任务是指接入任务调度系统的服务将需要执行的任务提交到任务队列中。拉取任务是指接入任务调度系统的服务在启动后由单独的线程对项目中配置的所有任务所对应的任务队列进行周期性轮询，如果从任务队列中提取到了任务则异步执行该任务。

提交任务和拉取任务的执行没有严格时序。一旦服务生成新的任务，即可将该任务提交到相应的任务队列，而拉取任务则按照设定的周期进行。

当服务启动后，服务客户端可读取预先配置的任务配置信息，根据任务配置信息生成任务队列，其中一个项目中的一个任务名称对应一个任务队列。当服务客户端生成任务后，根据所述任务配置信息，将该任务存储到相应的任务队列。一个任务队列对应于一部分存储空间，将任务存储到相应的任务队列是指在该任务队列对应的存储空间存储该任务的相关信息。其中，所述存储空间可以由用于存储任务队列的存储介质来实现。举例来说，如果使用Mysql作为任务队列，则客户端将其生成的任务存储到Mysql所在的磁盘上；如果使用Redis作为任务队列，则客户端将其生成的任务存储到Redis所在的内存中。

可选地，所存储的任务的相关信息可包括任务名称和任务参数，进一步还可包括任务所属项目的项目名称，可选地，还可包括任务有效时间和任务超时时间。其中，任务参数是在服务客户端生成任务时动态生成的，是执行该任务所需的参数。将任务参数存储到任务队列之前，可对任务参数进行JSON(JavaScript Object Notation，JS对象简谱)序列化，即，将任务参数转换为JSON格式，存储到任务队列中的任务参数为JSON序列化后的值。

JSON是一种轻量级的数据交换格式。采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得JSON成为理想的数据交换语言。易于阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

图1示例性示出了本申请实施例中任务提交原理框架图。如图所示，该示例场景下有2个服务，分别为服务A和服务B。在服务A中包含2个任务种类，分别为任务X和任务Y，在服务B中包含1个任务种类，为任务Z。服务A实例化为2个应用实例，为服务A配置有2个客户端(客户端1和客户端2)，分别运行服务A的2个应用实例。服务B实例化为1个应用实例，为服务B配置有1个客户端(客户端3)，运行服务B的应用实例。服务A可生成任务X和任务Y两种任务，其中，服务A的两个客户端既可生成任务X也可生成任务Y。服务B可生成任务Z一种任务。其中，任务X、任务Y和任Z表示任务名称不同的任务，也即不同种类的任务。

任务队列包括任务队列X、任务队列Y和任务队列Z。任务队列X用于存储任务X，任务队列Y用于存储任务Y，任务队列Z用于存储任务Z。

在服务运行过程中，服务A的客户端(包括客户端1和客户端2)生成任务X后，将任务X存储到任务队列X，服务A的客户端生成任务Y后，将任务Y存储到任务队列Y；服务B的客户端(客户端3)生成任务Z后，将任务Z存储到任务队列Z。

在任务执行过程中，为服务配置的客户端按照设定周期对该服务中的所有任务队列进行轮询，一旦从任务队列获取到任务，则异步执行该任务。具体地，针对一个服务，为其配置的客户端上存在有独立的线程，该线程的作用是按照设定周期对该服务中的所有任务队列进行轮询。

图2示例性示出了本申请实施例中任务拉取原理框架图。仍以图1的场景为例描述，客户端1按照设定周期对服务A中的所有任务队列，即任务队列X和任务队列Y，进行轮询，对于从上述任务队列中获取到的任务进行异步执行。客户端2按照设定周期对服务A中的所有任务队列，即任务队列X和任务队列Y，进行轮询，对于从上述任务队列中获取到的任务进行异步执行。客户端3按照设定周期对服务B中的所有任务队列，即任务队列Z，进行轮询，对于从上述任务队列中获取到的任务进行异步执行。

本申请的一些实施例中，为了对同一种任务的批量处理数量进行控制，针对任务轮询，引入了具体到任务维度的批量处理数量门限，称为单机并发数量(concurrent size)门限。该门限用于规定一种任务在一个服务客户端上最多可同时执行的数量。对于同一种任务(即名称相同的任务)，设置该种任务对应的单机并发数量门限。

比如，仍以图1和图2所示的场景为例，对于任务X，设置任务X对应的单机并发数量门限x，对于任务Y，设置任务Y对应的单机并发数量门限y，对于任务Z，设置任务Z对应的单机并发数量门限z。这样，客户端1上执行的任务X的数量不会超过单机并发数量门限x，执行的任务Y的数量不会超过单机并发数量门限y；客户端2上执行的任务X的数量不会超过单机并发数量门限x，执行的任务Y的数量不会超过单机并发数量门限y；客户端3上执行的任务Z的数量不会超过单机并发数量门限z。

为了实现上述对同一种任务的批量处理数量进行控制的目的，本申请的一些实施例中，以第一服务为例，第一服务的客户端根据为第一服务配置的任务配置信息，确定需要获取的任务种类；然后，根据需要获取的任务种类，确定本客户端当前执行的与该任务种类相同种类的任务的数量是否小于该任务种类对应的单机并发数量门限，若是，则从与该任务种类对应的任务队列中取出任务并异步执行；否则，按照上述流程处理第一服务中的其他种类的任务。

一般情况下，一个服务中包含多种任务，此种情况下，上述流程中，第一服务的客户端依次针对第一服务包含的每种任务，执行以下步骤，直到满足结束条件为止：针对当前任务种类，确定第一服务的客户端当前执行的该种任务数量是否小于该种任务对应的单机并发数量门限，若是，则从与该种任务对应的任务队列中获取一个任务，否则，获取下一个任务种类作为当前任务种类。

其中，可选地，所述结束条件可包括以下中的一个：

结束条件1：第一服务的客户端当前执行的每种任务的数量等于对应任务种类的单机并发数量门限。即，该客户端上，每种任务的数量均达到对应的单机并发数量门限。

结束条件2：第一服务的客户端当前执行的任务中，一部分任务种类中的每种任务的数量等于对应任务种类的单机并发数量门限，其余部分任务种类中的每种任务对应的任务队列为空。即，该客户端上，一部分种类的任务的数量达到对应的单机并发数量门限，其余部分种类的任务所对应的任务队列为空，无法提取新的任务。

图3示例性示出了本申请实施例中一种通用的任务调度流程示意图。本流程以第一服务为例描述，如图所示，在一个周期内，第一服务的客户端执行的任务调度流程可包括：

S301：第一服务的客户端根据为第一服务配置的任务配置信息，确定需要获取的任务种类。

该步骤中，第一服务的客户端根据为第一服务配置的任务配置信息，确定需要获取第一服务包含的所有任务种类。

S302：第一服务的客户端从需要获取的任务种类中确定当前任务种类。

S303：第一服务的客户端判断本客户端上执行的与当前任务种类同种类的任务的数量，是否小于当前任务种类所对应的单机并发数量门限，若是，则转入S304，否则转入S305。

S304：第一服务的客户端从当前任务种类对应的任务队列中获取一个任务并异步执行。并转入S305。

S305：第一服务的客户端判断是否满足结束条件，若满足，则结束本周期的任务拉取流程，否则转入S302以获取下一个任务种类作为当前任务种类，并重复执行上述流程。

其中，所述结束条件可参见前述实施例的描述，在此不再重复。

需要说明的是，如果为第一服务配置有多个客户端，则第一服务的每个客户端均按照上述图3所示的流程获取任务。

为了实现上述对同一种任务的批量处理数量进行控制的目的，本申请另外的一些实施例中，以当前的任务种类为第一种类为例，在保证客户端上执行的第一种类的任务数量不超过第一种类任务所对应的单机并发数量门限的情况下，客户端可以一次性从任务队列中获取多个任务并异步执行。

根据上述图3所示的流程，仍以图1和图2所示的场景为例，则客户端1和客户端2进行任务拉取的流程可如图4所示，客户端3进行任务拉取的流程磕入图5所示。

如图4所示，以客户端1为例，在一个轮询周期，客户端1执行任务拉取的流程可包括如下步骤：

S401：客户端1确定需要拉取的任务种类，本例子中，客户端1确定需要拉取的任务种类包括任务X和任务Y。

该步骤中，客户端1是服务A的客户端，客户端1获取为服务A配置的任务配置信息，由于该任务配置信息中配置了任务X和任务Y，因此客户端1可以确定需要拉取的任务种类包括任务X和任务Y。

在具体实施时，服务A的任务配置信息可以被加载到内存中，在内存中形成服务A的任务列表，客户端1可以通过读取该任务列表确定需要拉取的任务种类。

S402：客户端1判断本客户端上当前执行的任务X的数量是否小于任务X对应的单机并发数量门限x，若是，则转入S403，否则转入S404。

S403：客户端1从任务队列X获取一个任务并异步执行，并转入S404。

其中，任务队列X中当前可能存储有任务，也可能当前任务队列X为空(即任务队列X中未存储有任务)，相应地，如果任务队列当前存储有任务，则客户端1能够从任务队列X获取到任务，如果任务队列当前为空，则客户端1无法从任务队列X获取到任务。如果客户端1从任务队列X获取到任务则异步执行该任务，如果客户端从任务队列未获取到任务，则执行后续步骤。

S404：客户端1判断当前执行的任务Y的数量是否小于任务Y对应的单机并发数量门限y，若是，则转入S405，否则结束本次轮询。

S405：客户端1从任务队列Y获取一个任务并异步执行，并返回S402。

其中，任务队列Y中当前可能存储有任务，也可能当前任务队列Y为空(即任务队列Y中未存储有任务)，相应地，如果任务队列当前存储有任务，则客户端1能够从任务队列Y获取到任务，如果任务队列当前为空，则客户端1无法从任务队列Y获取到任务。如果客户端1从任务队列Y获取到任务，则异步执行该任务，如果客户端从任务队列未获取到任务，则执行后续步骤。

可选地，如果S403中客户端1未获取到任务X，且在S405中未获取到任务Y，则表明任务队列X和任务队列Y为空，此种情况下可结束本次轮询。

可选地，在另外的实施例中，如果S403中客户端1未获取到任务X，且在S405中未获取到任务Y，则可以返回S402，如果再次发生未获取到任务X和任务Y的情况，则该情况连续发生的次数若达到预先设置的次数门限，则结束本次轮询。

客户端2所执行的任务拉取流程与客户端1所执行的任务拉取流程基本相同，在此不再重复。

需要说明的是，以上图4所示的流程仅为示例，在实际应用中，任务轮询的顺序可不受上述流程的限制，比如可以首先轮询任务队列Y再轮询任务队列X。

如图5所示，以客户端3为例，在一个轮询周期，客户端3执行任务拉取的流程可包括如下步骤：

S501：客户端3确定需要拉取的任务种类，本例子中，客户端3确定需要拉取的任务种类为任务Z。

该步骤中，客户端3是服务B的客户端，客户端3获取为服务B配置的任务配置信息，由于该任务配置信息中仅配置了任务Z，因此客户端3可以确定需要拉取的任务种类为任务Z。

在具体实施时，服务B的任务配置信息可以被加载到内存中，在内存中形成服务B的任务列表，客户端3可以通过读取该任务列表确定需要拉取的任务种类。

S502：客户端3判断本客户端上当前执行的任务Z的数量是否小于任务Z对应的单机并发数量门限z，若是，则转入S503，否则结束本次轮询。

S503：客户端3从任务队列Z获取一个任务并异步执行，并转入S502。

其中，任务队列Z中当前可能存储有任务，也可能当前任务队列Z为空(即任务队列Z中未存储有任务)，相应地，如果任务队列当前存储有任务，则客户端3能够从任务队列Z获取到任务，如果任务队列当前为空，则客户端3无法从任务队列Z获取到任务。如果客户端3从任务队列Z获取到任务则异步执行该任务Z，如果客户端从任务队列未获取到任务则执行后续步骤。

可选地，如果S503中客户端3未获取到任务Z，则表明任务队列Z为空，此种情况下可结束本次轮询，也可以返回S502。进一步地，返回S502后，果再次发生未获取到任务Z的情况，则该情况连续发生的次数若达到预先设置的次数门限，则结束本次轮询。

可选地，在本申请的一些实施例中，可为一种任务配置该种任务的任务有效时间，当该一个任务被从任务队列取出后，可根据为该任务所属的任务种类配置的任务有效时间对，该任务的有效状态或失效状态进行判决。判决方法可以采用懒汉模式，即当该任务被服务从队列中取出后，在该任务被执行前对该任务进行有效状态或失效状态的判决，如果该任务被取出到当前的时间长度大于或等于该任务的有效时间，则判决该任务失效，否则判决该任务有效。如果判决该任务失效，则可以将该任务的状态更新为失效状态，状态为失效的任务不再被执行。进一步地，若判决一个任务失效，则可以从对应的任务队列中获取下一个任务。

可选地，在本申请的一些实施例中，可为一种任务配置任务超时时间，可根据为该任务配置的超时时间对该种任务的执行情况进行判决。若执行该任务所用的时间长度大于或等于该任务所属的任务种类所对应的任务超时时间，则判决该任务执行超时。可选地，对于判决为执行超时的任务，则可以将其状态更新为“执行失败”状态，该任务不再被执行，也不会将该任务再放回到任务队列。

具体实施时，在服务启动后，可启动一个独立的线程用于轮询当前实例正在执行的任务信息，以判断任务是否超过为该任务配置的超时时间，若已超时则中断该任务，并更新该任务的状态。

本申请实施例中，考虑到一个多次执行都会超时的任务有可能导致整个任务队列堵死，因此本申请实施例中，对于判决为执行超时的任务，可不对其进行多次重试处理。

可选地，在本申请的一些实施例中，一个任务执行成功后，还可针对该任务执行其他相关处理。比如，在任务执行成功后，可记录任务执行成功的日志、发送任务执行成功的通知等操作。可选地，接收到该通知的客户端，可以在满足设定条件的情况下向该任务对应的任务队列提交一个新的任务。其中，所述设定条件可以是任务队列未达到最大容量，本申请实施例对此不做限制。

可选地，在本申请的一些实施例中，若一个任务执行失败，则还可针对该任务执行其他相关处理。比如，可记录任务执行失败的日志、发送任务执行失败的告警通知等操作。可选地，还可以将执行失败的任务放回任务队列，以便后续再次执行该任务，如果一个任务执行失败的次数超过设定次数，则不再将该任务放回任务队列。

基于相同的技术构思，本申请实施例还提供了一种分布式任务调度装置，该装置可实现前述实施中图3至图5所执行的流程。

图6示例性示出了本申请实施例中的分布式任务调度装置600的结构示意图。如图所示，该装置可包括：任务获取模块601以及任务执行模块602，进一步地还可包括任务提交模块603。

任务获取模块601，用于根据为第一服务配置的任务配置信息，确定需要获取的任务的种类；其中，所述任务配置信息包括所述第一服务包含的任务种类信息；以及，根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务；其中，与所述种类对应的任务队列用于存储所述种类的任务；

任务执行模块602，用于异步执行任务获取模块601从任务队列取出的任务。

任务提交模块603，用于生成任务后，根据生成的任务所属的任务种类，将生成的任务提交到该任务种类对应的任务队列。

上述装置600中各模块所实现的功能，可参见前述实施例的描述，在此不再赘述。

基于相同的技术构思，本申请实施例还提供一种分布式任务调度装置，该装置可实现前述实施中图3至图5所执行的流程。

图7示例性示出了本申请实施例中的分布式任务调度装置700的结构示意图，即示出了装置600的另一结构示意图。参阅图7所示，该装置700包括处理器701、存储器702以及通信接口703。其中，处理器701也可以为控制器。所述处理器701被配置为支持该装置执行前述流程涉及的功能。存储器702用于与处理器701耦合，其保存终端必要的程序指令和数据。其中，处理器701、和存储器702相连，该存储器702用于存储指令，该处理器701用于执行该存储器702存储的指令，以完成上述方法中客户端执行相应功能的步骤。

本申请实施例中，装置700和装置600所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其它步骤请参见前述方法或其它实施例中关于这些内容的描述，此处不做赘述。

需要说明的是，本申请实施例上述涉及的处理器可以是中央处理器(centralprocessing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其它可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。其中，所述存储器可以集成在所述处理器中，也可以与所述处理器分开设置。

基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质。计算机可读存储介质存储有计算机可执行指令，计算机可执行指令用于使计算机执行本申请中客户端侧执行的流程。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

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

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种分布式任务调度方法，其特征在于，包括：

第一服务的客户端根据为所述第一服务配置的任务配置信息，确定需要获取的任务的种类；其中，所述任务配置信息包括所述第一服务包含的任务种类信息；

所述第一服务的客户端根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务并异步执行；其中，与所述种类对应的任务队列用于存储所述种类的任务。

2.如权利要求1所述的方法，其特征在于，所述需要获取的任务的种类至少为一种；

所述第一服务的客户端根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务，包括：

所述第一服务的客户端依次针对所述至少一种任务中的每种任务，执行以下步骤，直到满足结束条件为止：

针对当前任务种类，确定所述第一服务的客户端上执行的该种任务的数量是否小于该种任务对应的单机并发数量门限，若是，则从该种任务对应的任务队列中获取一个任务，否则，获取下一个任务种类作为当前任务种类。

3.如权利要求2所述的方法，其特征在于，所述结束条件包括：

所述第一服务的客户端当前执行的所述至少一种任务中的每种任务的数量等于对应任务种类的单机并发数量门限；或者，

所述第一服务的客户端当前执行的所述至少一种任务中，一部分任务种类中的每种任务的数量等于对应任务种类的单机并发数量门限，其余部分任务种类中的每种任务对应的任务队列为空。

4.如权利要求1所述的方法，其特征在于，所述从所述种类对应的任务队列中取出任务并异步执行，包括：

所述第一服务的客户端从所述种类对应的任务队列中取出任务后并在执行该任务之前，根据所述种类对应的任务有效时间，判断被取出的任务从取出到当前的时间长度是否小于所述任务有效时间，若是，则执行所述被取出的任务。

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

所述第一服务的客户端根据为当前执行的任务所属的任务种类配置的任务执行时间，判断所述当前执行的任务的执行时间长度是否大于或等于所述任务执行时间，若是，则结束执行所述当前执行的任务。

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

若任务执行成功，则记录任务执行成功的日志，发送任务执行成功的通知；

若任务执行失败，则记录任务执行失败的日志，发送任务执行失败的通知。

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

第一服务的客户端生成任务后，根据生成的任务所属的任务种类，将生成的任务提交到该任务种类对应的任务队列。

8.如权利要求1-7中任一项所述的方法，其特征在于，为所述第一服务配置的任务配置信息，还包括：

为所述第一服务包含的至少一个任务种类配置的与相应任务种类对应的任务有效时间，所述任务有效时间用于在执行被取出的相应种类的任务前判决该任务是否有效；和/或，

为所述第一服务包含的至少一个任务种类配置的与相应任务种类对应的任务执行时间，所述任务执行时间用于判决相应种类的任务的执行时间是否超时。

9.一种分布式任务调度装置，其特征在于，包括：

任务获取模块，用于根据为第一服务配置的任务配置信息，确定需要获取的任务的种类；其中，所述任务配置信息包括所述第一服务包含的任务种类信息；以及，根据所述需要获取的任务的种类，确定所述第一服务的客户端当前执行的与所述种类相同种类的任务的数量小于所述种类对应的单机并发数量门限，则从所述种类对应的任务队列中取出任务；其中，与所述种类对应的任务队列用于存储所述种类的任务；

任务执行模块，用于异步执行所述任务获取模块从任务队列取出的任务。

10.如权利要求9所述的装置，其特征在于，还包括：

任务提交模块，用于生成任务后，根据生成的任务所属的任务种类，将生成的任务提交到该任务种类对应的任务队列。

11.一种分布式任务调度装置，其特征在于，包括：处理器、存储器；所述处理器，用于读取所述存储器中的计算机指令，执行如权利要求1-8中任一项所述的方法。

12.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行如权利要求1-8中任一项所述的方法。

Images