CN118295815A - 异步任务处理方法、装置、设备、介质和程序产品 - Google Patents

Abstract

本公开提供了一种异步任务处理方法，可以应用于大数据和金融技术领域。该异步任务处理方法包括：响应于任务处理请求，生成第一任务。通过消息队列对第一任务进行分配，并转换得到多个第二任务。以及通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。本公开还提供了一种异步任务处理装置、设备、存储介质和程序产品。

Description

异步任务处理方法、装置、设备、介质和程序产品

技术领域

本公开涉及大数据和金融技术领域，具体涉及异步任务处理领域，更具体地涉及一种异步任务处理方法、装置、设备、介质和程序产品。

背景技术

web异步任务处理是一种web***任务执行机制，它不会立即返回结果，而是在后台进行处理。该方式对于耗时较长，不需要立即获得结果的任务非常实用。

在分布式集群环境下，传统web异步任务处理机制通常采用基于预先分配任务、基于关系数据和基于分布式文件***等方式，来实现异步任务分配。

然而，上述异步任务处理方式存在不够灵活、实时性较差等问题。

发明内容

鉴于上述问题，本公开的实施例提供了提高异步任务处理灵活性和处理效率的异步任务处理方法、装置、设备、介质和程序产品。

根据本公开的第一个方面，提供了一种异步任务处理方法，包括：响应于任务处理请求，生成第一任务。通过消息队列对第一任务进行分配，并转换得到多个第二任务。以及通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。

根据本公开的实施例，响应于任务处理请求，生成第一任务包括：响应于多个任务处理请求，通过分布式服务集群生成多个第一任务。将多个第一任务***异步任务清单表。

根据本公开的实施例，通过消息队列对第一任务进行分配，并转换得到多个第二任务包括：通过第一生产方对多个第一任务进行封装，得到多个第一消息，各第一消息包括目的地信息。根据目的地信息，通过消息队列将多个第一消息分配至多个第一消费方。以及分别通过多个第一消费方对相应的第一消息进行拆解，得到多个第二任务。

根据本公开的实施例，通过消息队列将多个第一消息分配至多个第一消费方包括：采用轮询、平均分发和按优先级分发中的任意一种或多种策略将多个第一消息分配至多个第一消费方。

根据本公开的实施例，多个第二任务存储于异步任务清单表，通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果包括：定时从异步任务清单表中读取预设数量的第二任务。通过第二生产方对第二任务进行封装，得到多个第二消息，各第二消息包括目的地信息。根据目的地信息，通过消息队列将多个第二消息分配至多个第二消费方。以及分别通过多个第二消费方对多个第二消息进行处理，得到任务处理结果。

根据本公开的实施例，异步任务清单表设置于关系型数据库，方法还包括：通过分布式缓存对多个第二任务进行缓存。在对第二任务进行封装之前，通过分布式缓存判断第二任务的节点占用状态。

根据本公开的实施例，消息队列为多条，分配第一任务与第二任务的消息队列相同或不同。

根据本公开的实施例，各第一消息和/或第二消息还包括消息优先级，方法还包括：在消息优先级小于预设阈值的情况下，转存第一消息和/或第二消息到数据库或文件***。

根据本公开的实施例，在通过消息队列对第一任务进行分配之前，方法还包括：对任务处理请求进行格式和类型的校验。

本公开的第二方面提供了一种异步任务处理装置，包括：生成模块，用于响应于任务处理请求，生成第一任务；转换模块，用于通过消息队列对第一任务进行分配，并转换得到多个第二任务；以及处理模块，用于通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。

本公开的第三方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述异步任务处理方法。

本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述异步任务处理方法。

本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述异步任务处理方法。

与现有技术相比，本公开提供的异步任务处理方法、装置、电子设备、存储介质和程序产品，至少具有以下有益效果：

(1)本公开的异步任务处理方法，采用两级任务处理机制将任务处理请求分别进行第一任务和第二任务的分发处理，提高了异步任务处理的效率。同时，结合消息队列，将任务处理过程解耦，提高了***响应时效和稳定性。

(2)本公开的异步任务处理方法，通过分布式服务集群处理大量高并发的任务请求，灵活度高，进一步提高了异步任务处理的效率。同时，采用异步任务清单表来统筹管理任务进度，也利于任务的状态同步，提高了***稳定性。

(3)本公开的异步任务处理方法，具体通过压缩文件的方式，对多个任务处理请求进行异步处理，在经过初次分配后，拆解得到多个解压任务，并进行二次分配处理，简便高效。

附图说明

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

图1示意性示出了根据本公开实施例的异步任务处理方法、装置、设备、介质和程序产品的应用场景图；

图2示意性示出了根据本公开实施例的异步任务处理方法的流程图；

图3示意性示出了根据本公开实施例的生成第一任务的方法流程图；

图4示意性示出了根据本公开实施例的生成多个第二任务的方法流程图；

图5示意性示出了根据本公开实施例的分配第一消息的方法流程图；

图6A示意性示出了根据本公开实施例的得到任务处理结果的方法流程图；图6B示意性示出了根据本公开实施例的异步任务处理方法的逻辑流程图；

图7示意性示出了根据本公开另一实施例的异步任务处理方法的流程图；

图8示意性示出了根据本公开又一实施例的异步任务处理方法的流程图；

图9示意性示出了根据本公开又一实施例的异步任务处理方法的流程图；

图10示意性示出了根据本公开实施例的异步任务处理装置的结构框图；以及

图11示意性示出了根据本公开实施例的适于实现异步任务处理方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。

本公开实施例提供一种异步任务处理方法、装置、设备、介质和程序产品，可用于金融领域或其他领域。需要说明的是，本公开的异步任务处理方法、装置、设备、介质和程序产品可用于金融领域，也可用于除金融领域之外的任意领域，本公开的异步任务处理方法、装置、设备、介质和程序产品的应用领域不做限定。

在本公开的技术方案中，所涉及的用户信息(包括但不限于用户个人信息、用户图像信息、用户设备信息，例如位置信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、存储、使用、加工、传输、提供、公开和应用等处理，均遵守相关法律法规和标准，采取了必要保密措施，不违背公序良俗，并提供有相应的操作入口，供用户选择授权或者拒绝。

在利用个人信息进行自动化决策的场景下，本公开实施例提供的方法、设备和***均为用户提供相应的操作入口，供用户选择同意或者拒绝自动化决策结果；若用户选择拒绝，则进入专家决策流程。此处的表述“自动化决策”是指通过计算机程序自动分析、评估个人的行为***的人员进行决策的活动。

本公开的实施例提供了一种异步任务处理方法，包括：响应于任务处理请求，生成第一任务。通过消息队列对第一任务进行分配，并转换得到多个第二任务。以及通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。本公开的异步任务处理方法，提高了异步任务处理的效率，以及***响应时效和稳定性。

图1示意性示出了根据本公开实施例的异步任务处理方法、装置、设备、介质和程序产品的应用场景图。

如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的异步任务处理方法一般可以由服务器105执行。相应地，本公开实施例所提供的异步任务处理装置一般可以设置于服务器105中。本公开实施例所提供的异步任务处理方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的异步任务处理装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

首先，对本公开实施例的相关名词术语作如下解释：

任务(Task)：异步任务是需要在后台执行的工作单元，它可以是任何需要一定时间完成的操作，例如文件上传、邮件发送、数据处理等。

异步(Asynchronous)：异步表示任务不会阻塞程序的执行，而是在后台进行。与同步(Synchronous)相对，同步任务通常需要等待任务完成后才能继续执行下一步操作，而异步任务可以在任务执行的同时继续执行其他操作。

消息队列(Message Queue)：消息队列是一种通信机制，用于在不同的组件、服务或***之间传递消息。在异步任务处理中，消息队列常常被用于将任务放入队列中，由后台的工作者进程或服务逐个处理。

发布-订阅模式(Publish-Subscribe Pattern)：异步任务处理中的发布-订阅模式允许一个组件发布事件，而其他组件则订阅这些事件。这种模式通常用于实现任务的通知和响应。

回调函数(Callback Function)：回调函数是在异步任务完成时执行的函数。当任务完成时，***会调用预定义的回调函数，以便进行后续处理。

并发性(Concurrency)：异步任务处理通常与并发性相关。通过异步执行任务，***可以更充分地利用资源，提高***的性能和响应能力。

以下将基于图1描述的场景，通过图2～图9对公开实施例的异步任务处理方法进行详细描述。

图2示意性示出了根据本公开实施例的异步任务处理方法的流程图。

根据本公开的实施例，如图2所示，该实施例的异步任务处理方法例如包括操作S210～操作S230，该异步任务处理方法可以由计算机程序在相应计算机硬件上执行。

在操作S210，响应于任务处理请求，生成第一任务。

在操作S220，通过消息队列对第一任务进行分配，并转换得到多个第二任务。

在操作S230，通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。

在一些实施例中，例如需要进行在线购物平台的订单处理任务。

当用户在在线购物平台提交订单时，***会响应这个订单处理请求。***根据订单信息生成一个“处理订单”的第一任务。

这个任务被放入一个消息队列中，等待分配。消息队列中的“处理订单”任务被取出，根据订单处理流程，被转换成多个第二任务，例如“确认订单信息”、“生成支付链接”、“发送订单确认邮件”等。

这些第二任务再次被放入消息队列中，等待处理。消息队列的分配机制确保这些任务被分配给合适的处理单元(例如不同的服务器或线程)。各个处理单元接收到任务后，开始处理，例如确认订单信息无误、生成支付链接供用户支付、向用户发送确认邮件等。处理完成后，每个任务都会生成相应的处理结果，并返回给***。

在一些实施例中，例如需要进行视频编辑软件的渲染任务。

用户在视频编辑软件中完成编辑后，点击“渲染”按钮，***响应渲染请求。***根据用户选择的渲染参数生成一个“渲染视频”的第一任务。

这个任务被放入一个专门用于视频渲染的消息队列中。由于视频渲染可能涉及多个阶段(如音频处理、视频编码、特效合成等)，第一任务被转换成多个第二任务，并分别放入消息队列。

消息队列根据各处理单元(渲染服务器)的负载情况，智能地将任务分配给空闲或负载较低的处理单元。处理单元接收任务后开始渲染工作，每个阶段完成后都会生成相应的处理结果，并最终合成完整的渲染视频。

这两个实施例展示了异步任务处理方法在不同场景中的应用，通过消息队列的分配和处理机制，实现了任务的分解、分配和并行处理，提高了***的处理能力和效率。

在操作S210，获取任务处理请求可能涉及获取用户信息。

在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权。例如，在操作S210之前，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，执行所述操作S210。

在操作S230，利用所述用户信息进行后续动作执行的处理，以实现对终端的操作或信息的获取等。

在本公开的实施例中，可以为用户提供相应的操作入口，供用户选择同意或者拒绝自动化决策结果。即，在对所述用户信息进行后续动作执行的处理之前，可以获得用户通过相应的操作入口输入的同意或拒绝进行所述处理的指令。如果用户同意进行所述处理/决策，则对所述用户信息进行后续动作执行的处理，即执行步骤S230。如果用户拒绝进行所述处理，则进入专家决策流程。

图3示意性示出了根据本公开实施例的生成第一任务的方法流程图。

根据本公开的实施例，如图3所示，例如通过操作S311～操作S312来响应于任务处理请求，生成第一任务。

在操作S311，响应于多个任务处理请求，通过分布式服务集群生成多个第一任务。

在操作S312，将多个第一任务***异步任务清单表。

在一些实施例中，例如一个大型电商平台的订单处理任务。

在大型电商平台的运营过程中，由于用户众多且活跃度高，经常会同时接收到大量的订单处理请求。为了高效处理这些请求，平台采用了分布式服务集群和异步任务处理的方法。

当用户在电商平台上成功提交订单时，***会接收到一个订单处理请求。由于同时有多个用户下单，***会在短时间内接收到大量的订单处理请求。

为了应对大量的请求，电商平台部署了分布式服务集群。每个服务节点都具备处理订单的能力。

当***接收到订单处理请求时，它会根据负载均衡策略将请求分配给集群中的一个或多个服务节点。

每个服务节点接收到请求后，会根据订单信息生成对应的“处理订单”的第一任务。由于有多个服务节点同时工作，因此可以快速地生成多个第一任务。

生成第一任务后，为了实现对这些任务的统一管理和调度，***会将这些任务***到一个异步任务清单表中。

这个异步任务清单表可以是一个数据库表，也可以是其他形式的存储结构，用于存储任务的相关信息，如任务ID、任务类型、任务状态、创建时间等。

通过将任务***清单表，***可以方便地追踪每个任务的处理进度和状态，确保任务得到正确的处理。

通过这种方式，电商平台可以高效地处理大量的订单处理请求，通过分布式服务集群生成多个第一任务，并将它们***异步任务清单表进行统一管理。后续，这些任务可以通过消息队列进行分配和处理，进一步提高***的吞吐量和处理效率。

图4示意性示出了根据本公开实施例的生成多个第二任务的方法流程图。

根据本公开的实施例，如图4所示，例如通过操作S421～操作S423来通过消息队列对第一任务进行分配，并转换得到多个第二任务。

在操作S421，通过第一生产方对多个第一任务进行封装，得到多个第一消息，各第一消息包括目的地信息。

在操作S422，根据目的地信息，通过消息队列将多个第一消息分配至多个第一消费方。以及

在操作S423，分别通过多个第一消费方对相应的第一消息进行拆解，得到多个第二任务。

在一些实施例中，任务处理请求可以表征为Zip文件，例如有一个基于Zip文件的图像处理任务。

在一个图像处理***中，用户需要将大量的图片压缩成Zip文件，并上传至***进行处理。***接收到这些Zip文件后，会生成对应的图像处理任务，并通过消息队列进行分配和转换。

用户将需要处理的图片打包成Zip文件，并通过***接口上传。每个Zip文件都包含了一组待处理的图片。

***接收到Zip文件后，首先生成一个“处理Zip文件”的第一任务。这个任务被封装成一个消息，并放入消息队列中等待分配。

第一生产方是***中负责处理任务分配和封装的组件。它会基于Zip文件生成“处理Zip文件”的任务，并对每个Zip文件进行封装。封装过程中，第一生产方会为每个Zip文件生成一个第一消息。这个第一消息除了包含Zip文件本身的数据外，还包含了目的地信息，即指明这个Zip文件应该被发送到哪个消费方进行处理。

第一生产方根据目的地信息，将封装好的第一消息再次放入消息队列中。消息队列根据配置的路由规则，将消息分发到对应的第一消费方。

第一消费方是***中负责实际处理任务的组件。它们会从消息队列中取出属于自己的第一消息，并开始处理。每个第一消费方接收到第一消息后，首先会提取出Zip文件。然后，它会对Zip文件进行拆解，将里面的每个图片文件都作为一个独立的处理单元。

对于每个图片文件，第一消费方会生成一个对应的“处理图片”的第二任务。这些第二任务可以根据具体的图像处理需求进行定义，比如调整图片大小、应用滤镜效果等。

生成第二任务后，第一消费方可以继续处理这些任务，或者将它们再次放入消息队列中，等待其他消费方进行处理。

根据***的设计和需求，第二任务可以并行处理，也可以按照特定的顺序进行处理。

通过上述步骤，***能够高效地处理大量的Zip文件，通过消息队列进行任务的分配和转换，最终得到多个具体的图像处理任务(第二任务)。这种方式不仅提高了***的处理效率，还使得任务处理过程更加灵活和可扩展。

图5示意性示出了根据本公开实施例的分配第一消息的方法流程图。

根据本公开的实施例，如图5所示，例如通过操作S5221来通过消息队列将多个第一消息分配至多个第一消费方。

在操作S5221，采用轮询、平均分发和按优先级分发中的任意一种或多种策略将多个第一消息分配至多个第一消费方。

在一些实施例中，例如有一个视频处理***中的分配任务。

在一个视频处理***中，用户上传了大量的视频文件，***需要将这些视频文件分配给不同的处理节点进行编码、转码或分析等操作。每个处理节点都可以视为一个第一消费方，而***则负责生成第一消息(包含视频文件信息)并通过消息队列进行分配。

采用轮询策略分配第一消息：

在轮询策略下，***按照固定的顺序逐个将第一消息分配给各个第一消费方。例如，如果有三个消费方X、Y、Z，***首先将第一个第一消息分配给X，然后将第二个第一消息分配给Y，接着将第三个第一消息分配给Z，以此类推。

这种策略简单且易于实现，但可能无法充分利用各消费方的处理能力，特别是在消费方处理能力不均等的情况下。

采用平均分发策略分配第一消息：

在平均分发策略下，***根据当前各消费方的负载情况，动态地将第一消息平均分配给各个消费方。***可以监控每个消费方的当前任务队列长度、处理速度等指标，然后根据这些指标计算每个消费方应该接收的消息数量。

这种策略可以更好地平衡各消费方的负载，提高整体处理效率。但实现起来相对复杂，需要***具备实时的负载监控和计算能力。

采用按优先级分发策略分配第一消息：

在按优先级分发策略下，***根据第一消息的优先级或视频文件的紧急程度来分配任务。例如，某些视频文件可能需要进行实时转码或高质量处理，因此它们会被赋予更高的优先级，并被优先分配给处理能力更强或当前负载较轻的消费方。

这种策略可以满足不同任务之间的优先级需求，确保关键任务得到及时处理。但需要对消息进行优先级标注，并在分配过程中进行优先级判断，增加了***的复杂性。

结合多种策略进行分配：

在实际应用中，***还可以根据具体需求和场景，结合上述多种策略进行第一消息的分配。例如，可以先采用轮询策略进行初步分配，然后根据消费方的实时负载情况进行动态调整；或者根据消息的优先级进行初步分类，再分别采用不同的分发策略进行分配。

通过这种结合不同分配策略的方式，视频处理***能够更加灵活和高效地处理大量的视频文件，确保每个文件都能得到及时和适当的处理。同时，这也为***提供了更好的扩展性和可配置性，以适应不同规模和复杂度的应用场景。

图6A示意性示出了根据本公开实施例的得到任务处理结果的方法流程图。图6B示意性示出了根据本公开实施例的异步任务处理方法的逻辑流程图。

根据本公开的实施例，多个第二任务存储于异步任务清单表，如图6A所示，例如通过操作S631～操作S634来通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。

在操作S631，定时从异步任务清单表中读取预设数量的第二任务。

在操作S632，通过第二生产方对第二任务进行封装，得到多个第二消息，各第二消息包括目的地信息。

在操作S633，根据目的地信息，通过消息队列将多个第二消息分配至多个第二消费方。以及

在操作S634，分别通过多个第二消费方对多个第二消息进行处理，得到任务处理结果。

在一些实施例中，如图6B所示，例如在一个zip文件(包含上百张excel报表文件)上传服务端，完成报表数据的合法校验、报表公式检查和运算的场景。

由客户端将打包了多张excel报表的zip文件提交前端***，zip文件经格式和类型校验，提交至服务端，服务端将zip文件处理转换为一条A编号的任务记录，***关系数据库的异步任务清单表中。

相关服务线程从异步任务表中取出A编号任务，将A编号任务拆解成一定数据量的B号任务，并将B号任务同样***异步任务清单表。其中，B号任务数量与A号任务zip文件中所包含的报表数量相对应。定时任务线程将从异步清单表中取B号任务完成报表的数据校验、公式检查和公式运算，最后，将验证运算后的报表数据入库。

在上述场景中，用户单次提交可产生数百个B号任务，对于用户规模数万的***，如何解决大规模异步任务的生成、分配和处理是本公开所要解决的核心问题。

为解决此类问题，本公开的实施例引入分布式消息队列机制，将异步任务的分发转交消息队列处理，其中任务的处理在集群(包含n个服务节点)环境下完成。

客户端提交的ZIP文件由服务集群中的任一节点(由负载均衡机制分配)线程处理，服务线程基于ZIP文件生成一条A号任务记录***异步任务表，同步将A号任务交由MQ的ProducerA(第一生产方)发送至MQ队列。

MQ队列基于负载均衡机制，将A任务均衡分配给集群中的多个第一消费方CusumerA，之后第一消费方将A号任务拆解转换成多条B号任务。此时，若A号任务转换失败，则通过回调函数更新任务清单表中A记录的状态为失败，否则更新为成功。

生成的B号任务将全量***任务清单表，待后续定时任务处理。

对于B号任务的处理，***定时任务每隔1分钟，按任务生成的时间顺序从任务清单表读取m条B号任务。与A号任务的处理逻辑类似，读取到的m条B号任务逐次交由ProducerB发送至MQ分配(ProducerB发送后，回调函数同步更新B号任务状态为处理中)，最终由集群中的多个ConsumerB任务节点消费处理。

在本***中一条B号任务对应一张待处理的报表，该报表将经过严格的数据校验、公式合法性检查和***的报表引擎公式运算，最终将派生出的合法报表数据入库。

报表数据入库后，将同步更新对应的B号任务状态为已完成。

在一些实施例中，例如有一个基于异步任务清单表的在线文档编辑任务。

在一个在线文档编辑***中，用户可以对文档进行编辑、保存和分享等操作。***会将用户的编辑请求转换成多个第二任务，并通过消息队列进行分配和处理。

当用户进行文档编辑操作时，***会生成对应的第二任务，如“更新文档内容”、“保存文档版本”等。这些第二任务会被存储在异步任务清单表中，等待后续处理。

异步任务清单表是一个持久化的存储结构，用于记录和管理***中的任务。每个任务在表中都有一条记录，包括任务ID、任务类型、任务状态、创建时间等信息。

***设置了一个定时任务，每隔一段时间(如每隔5分钟)从异步任务清单表中读取一定数量的第二任务。这个数量可以根据***的负载情况和处理能力进行配置。

定时任务会按照某种策略(如先进先出、优先级排序等)从表中选取任务，并将其标记为“待处理”状态，准备进行后续的分配和处理。

读取到第二任务后，***将其交给第二生产方进行处理。第二生产方负责将任务封装成消息格式，以便通过消息队列进行传递。

在封装过程中，第二生产方会为每个任务生成一个第二消息。这些消息除了包含任务的具体内容外，还包含了目的地信息，即指明这些任务应该被发送到哪个消费方进行处理。

封装好的第二消息被放入消息队列中等待分配。消息队列根据配置的路由规则和目标地信息，将消息分发到对应的第二消费方。

第二消费方是***中负责实际处理任务的组件。它们会从消息队列中取出属于自己的第二消息，并开始处理。

每个第二消费方接收到第二消息后，会解析出其中的任务内容，并执行相应的处理逻辑。例如，对于“更新文档内容”的任务，消费方可能会调用文档编辑引擎来更新文档内容；对于“保存文档版本”的任务，消费方可能会将文档保存到存储***中。

处理完成后，第二消费方会生成任务处理结果。这个结果可能是一个状态码、一条日志记录、或者是更新后的数据等，用于表示任务的处理情况。

任务处理结果可以存储在数据库中，以便后续查询和审计。同时，***还可以将结果反馈给用户或其他相关组件，例如通过API接口返回给用户，或者通过事件通知其他***组件。

通过上述步骤，***能够高效地处理大量的第二任务，通过异步任务清单表和消息队列进行任务的存储、分配和处理，并最终得到任务处理结果。这种方式不仅提高了***的处理能力和效率，还使得任务处理过程更加灵活和可扩展。

图7示意性示出了根据本公开另一实施例的异步任务处理方法的流程图。

根据本公开的实施例，异步任务清单表设置于关系型数据库，如图7所示，该实施例的异步任务处理方法例如还包括操作S710～操作S720。

在操作S710，通过分布式缓存对多个第二任务进行缓存。

在操作S720，在对第二任务进行封装之前，通过分布式缓存判断第二任务的节点占用状态。

在一些实施例中，例如有一个基于分布式缓存的异步视频处理任务。

在一个视频处理***中，用户上传视频后，***需要异步处理这些视频，例如进行转码、添加水印等操作。为了避免在处理任务时发生锁竞争，***采用了关系型数据库存储异步任务清单表，并结合分布式缓存来优化任务分配。

***使用关系型数据库(如MySQL)来存储异步任务清单表。这张表包含了所有待处理的视频处理任务，每个任务都有唯一的标识和状态信息。

当有新的视频上传时，***会在数据库中创建相应的任务记录，并设置其初始状态为“待处理”。

为了提高任务分配的效率，***引入了分布式缓存(如Redis)来缓存部分待处理的视频处理任务。

当***需要分配任务时，会首先查询分布式缓存中是否有可用的任务。如果有，则直接从缓存中获取任务，避免了对数据库的频繁访问。

当缓存中的任务被处理完毕或数量不足时，***会再从数据库中批量加载新的任务到缓存中。

在将任务分配给具体的处理节点之前，***首先会检查分布式缓存中该任务的节点占用状态。

分布式缓存中维护了一个任务到节点的映射关系，记录了哪些任务正在被哪些节点处理。***通过查询这个映射关系，可以快速判断一个任务是否已经被其他节点占用。

例如，为了降低频繁的锁表操作带来的开销，本公开实施例的方案绕开了采用数据库锁的方案，转而采用基于缓存***的分布式锁，如Redis来实现高性能的键值存储。

具体地，将A或B任务编号作为Redis中键(key)，是在Redis中设置键的值(value)，如果键不存在，则设置成功并返回1(当前任务未被其他节点处理)；如果键已经存在，则设置失败并返回0(当前任务正被处理)。同时，为避免客户端宕机，设置锁的过期时间来实现自动释放。

如果任务未被占用，***将其标记为“处理中”状态，并将其从缓存中移除，准备进行封装和分配。如果任务已被占用，则***会跳过该任务，继续查找其他可用的任务。

确定了未被占用的任务后，***通过第二生产方将这些任务封装成消息，并放入消息队列中。

消息队列根据配置的路由规则，将消息分发到不同的处理节点。每个处理节点负责执行具体的视频处理操作。

处理节点从消息队列中取出任务消息后，执行相应的视频处理操作。处理完成后，节点会更新任务的状态为“已完成”，并将结果存储到数据库中。

同时，节点还会将已完成任务的信息同步回分布式缓存中，以便***能够实时了解任务的完成情况。

***会定期监控任务的处理进度和状态，确保所有任务都能被及时处理。

如果某个处理节点出现故障或超时未处理任务，***会将相应的任务重新放回缓存中，等待其他节点处理。

通过结合关系型数据库和分布式缓存，以及在对任务进行封装前判断节点占用状态，视频处理***能够高效地管理异步任务，避免锁竞争，提高***的吞吐量和稳定性。

根据本公开的实施例，消息队列为多条，分配第一任务与第二任务的消息队列相同或不同。

在一些实施例中，例如针对一个在线订单处理任务。

在一个在线订单处理***中，用户提交订单后，***需要处理这些订单，包括订单验证、库存检查、支付处理等多个步骤。这些步骤可以视为第一任务，而每个第一任务可能又会进一步分解为多个第二任务，如库存检查的每个商品项可能是一个第二任务。

***设置多条消息队列，用于处理不同类型的任务。例如，可以有一个队列专门用于处理订单验证任务，另一个队列用于处理库存检查任务，还有一个队列用于处理支付任务。

对于第一任务和第二任务的分配，***可以灵活选择是否使用相同的消息队列。如果***希望简化处理逻辑，可以将第一任务和由此分解得到的第二任务都放入相同的队列中。如果***需要更精细的控制或并行处理，可以将它们放入不同的队列。

当用户提交订单时，***生成一个第一任务，即处理该订单。这个任务被封装成一个消息，并放入相应的消息队列中等待处理。

消息队列的消费者(如订单处理服务)从队列中取出任务消息，并开始处理。在处理过程中，***可能会将第一任务分解为多个第二任务。例如，订单处理服务可能会将订单验证、库存检查和支付处理作为第二任务分解出来。

对于分解得到的第二任务，***可以根据实际情况选择将它们放入与第一任务相同的队列，或者放入专门处理这类任务的队列。

如果放入相同队列，那么处理第一任务的消费者可以继续处理这些第二任务，或者由其他空闲的消费者接管。这种方式的优点是实现简单，但可能导致处理逻辑较为复杂。

如果放入不同队列，***可以根据任务的性质和优先级，将它们分配给不同的消费者组或处理节点。例如，库存检查任务可能需要访问库存***，因此可以将其放入一个与库存***紧密集成的消费者组或队列中。

由于使用了多条消息队列，***可以实现任务的并行处理。不同的消费者或处理节点可以同时从各自的队列中取出任务进行处理，从而提高整个***的吞吐量和响应速度。

同时，通过使用不同的队列，***还可以更好地控制任务的优先级和调度策略。例如，对于紧急订单或高优先级任务，***可以将其放入一个优先级较高的队列中，确保它们能够优先得到处理。

每个任务处理完成后，消费者会将处理结果反馈回***，并更新订单状态。如果处理过程中发生异常或错误，***会采取相应的异常处理机制，如重试、记录日志或通知管理员。

对于未处理或处理失败的任务，***可以将它们重新放回消息队列中等待再次处理，或者放入专门的异常处理队列中进行特殊处理。

通过以上步骤，消息队列在在线订单处理***中实现了任务的分解、分配和并行处理，提高了***的效率和可靠性。同时，通过使用多条消息队列和灵活的分配策略，***能够更好地满足业务需求和性能要求。

图8示意性示出了根据本公开又一实施例的异步任务处理方法的流程图。

根据本公开的实施例，各第一消息和/或第二消息还包括消息优先级，如图8所示，该实施例的异步任务处理方法例如还包括操作S810。

在操作S810，在消息优先级小于预设阈值的情况下，转存第一消息和/或第二消息到数据库或文件***。

在一些实施例中，例如有一个基于消息优先级的异步图像处理任务。

在一个图像处理***中，用户会上传图片并请求进行各种图像处理操作，如裁剪、滤镜应用等。这些请求被转换成异步任务，并通过消息队列进行分配和处理。

当用户上传图片并请求图像处理时，***会生成一个第一消息，并将其放入消息队列中等待处理。这个第一消息包含了图像处理的具体请求和参数。

根据图像处理请求的重要性和紧急性，***会为每个消息设置一个优先级。例如，对于需要快速处理的紧急请求，***可以将其优先级设置为高；对于常规请求，优先级可以设置为中；而对于不太重要或可以延迟处理的请求，优先级可以设置为低。

消息队列的消费者(如图像处理服务)会从队列中取出消息进行处理。在取出消息时，消费者可以根据消息的优先级进行选择。例如，它可以优先处理高优先级的消息，以确保紧急请求能够得到及时处理。

对于每个取出的消息，消费者会解析其内容并执行相应的图像处理操作。处理完成后，消费者会更新任务的状态，并返回处理结果。

当消息队列中存在大量低优先级的消息时，为了避免队列拥堵或资源浪费，***可以采取一种策略：将低优先级的消息转存到数据库或文件***中。

具体地，当消息的优先级小于预设阈值时(例如，优先级为“低”)，***会将该消息从消息队列中取出，并将其保存到数据库或文件***的指定位置。这样，这些消息就不会一直占用消息队列的资源，而是可以等待***资源空闲时再进行处理。

在转存消息时，***还可以记录一些额外的信息，如转存时间、原始队列信息等，以便后续能够方便地找回和处理这些消息。

当***资源较为空闲时，或者根据业务需求需要处理这些低优先级的消息时，***可以从数据库或文件***中取出这些消息，并将它们重新放入消息队列中等待处理。

在重新放入队列之前，***可以根据当前的资源情况和业务需求对消息进行再次排序或调整优先级。这样，即使这些消息是低优先级的，也能在合适的时机得到处理。

***会监控整个消息处理过程，包括消息的生成、分配、处理和转存等。对于每个步骤，***都会记录相应的日志信息，以便后续进行审计和故障排查。

通过监控和日志记录，***可以及时发现并处理异常情况，确保异步任务能够稳定、高效地执行。

通过结合消息优先级和转存机制，图像处理***能够更灵活地处理异步任务消息。它可以根据消息的紧急性和重要性进行优先级处理，同时避免低优先级消息对***资源的占用和浪费。这种方法有助于提高***的吞吐量和响应速度，同时保证重要任务能够得到及时处理。

图9示意性示出了根据本公开又一实施例的异步任务处理方法的流程图。

根据本公开的实施例，如图9所示，在通过消息队列对第一任务进行分配之前，该实施例的异步任务处理方法例如还包括操作S910。

在操作S910，对任务处理请求进行格式和类型的校验。

在一些实施例中，例如有一个基于请求校验的异步视频转码任务。

在一个视频处理平台中，用户上传视频并请求进行转码操作。这些转码请求被作为异步任务处理，并通过消息队列进行分配。为了确保任务处理的正确性和可靠性，***在分配任务之前对任务处理请求进行严格的格式和类型校验。

用户通过平台界面或API接口提交视频转码请求。***接收这些请求，并提取其中的关键信息，如源视频地址、目标格式、转码参数等。

在将请求转化为第一任务并放入消息队列之前，***首先对请求的格式进行校验。这包括检查请求的各个字段是否完整、是否符合预定义的格式要求。

例如，***会检查源视频地址是否是一个有效的URL，目标格式是否是一个支持的转码格式，转码参数是否符合预期的格式和范围等。

如果发现格式错误或缺失，***会返回错误提示给用户，并要求重新提交正确的请求。

除了格式校验外，***还会对请求的类型进行校验。这主要是为了确保请求符合预期的操作类型和业务逻辑。

在视频转码的场景中，类型校验可能包括检查请求是否是一个合法的转码请求，而不是其他类型的操作请求(如视频上传、删除等)。

***可以通过定义请求的类型标识或标签来实现类型校验。当接收到请求时，***会检查这些标识或标签，并与预定义的类型进行匹配。

只有当任务处理请求通过了格式和类型的校验后，***才会将其转化为第一任务，并放入消息队列中等待处理。

在放入队列之前，***还可以为任务设置一些额外的属性，如优先级、超时时间等，以便后续的消息队列消费者能够根据这些属性进行任务的分配和处理。

消息队列的消费者(如视频转码服务)会从队列中取出任务进行处理。由于已经经过了严格的格式和类型校验，消费者可以信任任务请求的有效性，并直接执行相应的转码操作。

如果在任务处理请求校验或后续处理过程中发生异常或错误，***会进行相应的异常处理，并记录详细的日志信息。

这些日志信息可以帮助***管理员和开发人员快速定位问题、进行故障排查和优化***性能。

通过对任务处理请求进行格式和类型的校验，视频转码***能够确保只有合法和有效的请求才会被放入消息队列进行异步处理。这有助于提高***的稳定性和可靠性，减少因无效请求导致的资源浪费和错误处理成本。

基于上述异步任务处理方法，本公开还提供了一种异步任务处理装置。以下将结合图10对该异步任务处理装置进行详细描述。

图10示意性示出了根据本公开实施例的异步任务处理装置的结构框图。

如图10所示，该实施例的装置1000例如包括：生成模块1010、转换模块1020和处理模块1030。

生成模块1010用于响应于任务处理请求，生成第一任务。在一实施例中，生成模块1010可以用于执行前文描述的操作S210，在此不再赘述。

转换模块1020用于通过消息队列对第一任务进行分配，并转换得到多个第二任务。在一实施例中，转换模块1020可以用于执行前文描述的操作S220，在此不再赘述。

处理模块1030用于通过消息队列对至少部分多个第二任务进行分配，并处理得到任务处理结果。在一实施例中，处理模块1030可以用于执行前文描述的操作S230，在此不再赘述。

根据本公开的实施例，生成模块1010、转换模块1020和处理模块1030中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，模生成模块1010、转换模块1020和处理模块1030中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，生成模块1010、转换模块1020和处理模块1030中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图11示意性示出了根据本公开实施例的适于实现异步任务处理方法的电子设备的方框图。

如图11所示，根据本公开实施例的电子设备1100包括处理器1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行各种适当的动作和处理。处理器1101例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器1101还可以包括用于缓存用途的板载存储器。处理器1101可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 1103中，存储有电子设备1100操作所需的各种程序和数据。处理器1101、ROM 1102以及RAM 1103通过总线1104彼此相连。处理器1101通过执行ROM 1102和/或RAM1103中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 1102和RAM 1103以外的一个或多个存储器中。处理器1101也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备1100还可以包括输入/输出(I/O)接口1105，输入/输出(I/O)接口1105也连接至总线1104。电子设备1100还可以包括连接至I/O接口1105的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/***中所包含的；也可以是单独存在，而未装配入该设备/装置/***中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的异步任务处理方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1102和/或RAM 1103和/或ROM 1102和RAM 1103以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机***中运行时，该程序代码用于使计算机***实现本公开实施例所提供的异步任务处理方法。

在该计算机程序被处理器1101执行时执行本公开实施例的***/装置中限定的上述功能。根据本公开的实施例，上文描述的***、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分1109被下载和安装，和/或从可拆卸介质1111被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被处理器1101执行时，执行本公开实施例的***中限定的上述功能。根据本公开的实施例，上文描述的***、设备、装置、模块、单元等可以通过计算机程序模块来实现。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (13)

1.一种异步任务处理方法，其特征在于，所述方法包括：

响应于任务处理请求，生成第一任务；

通过消息队列对所述第一任务进行分配，并转换得到多个第二任务；以及

通过所述消息队列对至少部分所述多个第二任务进行分配，并处理得到任务处理结果。

2.根据权利要求1所述的方法，其特征在于，所述响应于任务处理请求，生成第一任务包括：

响应于多个任务处理请求，通过分布式服务集群生成多个第一任务；

将所述多个第一任务***异步任务清单表。

3.根据权利要求2所述的方法，其特征在于，所述通过消息队列对所述第一任务进行分配，并转换得到多个第二任务包括：

通过第一生产方对多个所述第一任务进行封装，得到多个第一消息，各所述第一消息包括目的地信息；

根据所述目的地信息，通过所述消息队列将所述多个第一消息分配至多个第一消费方；以及

分别通过所述多个第一消费方对相应的第一消息进行拆解，得到所述多个第二任务。

4.根据权利要求3所述的方法，其特征在于，所述通过所述消息队列将所述多个第一消息分配至多个第一消费方包括：

采用轮询、平均分发和按优先级分发中的任意一种或多种策略将所述多个第一消息分配至所述多个第一消费方。

5.根据权利要求3所述的方法，其特征在于，所述多个第二任务存储于所述异步任务清单表，所述通过所述消息队列对至少部分所述多个第二任务进行分配，并处理得到任务处理结果包括：

定时从所述异步任务清单表中读取预设数量的所述第二任务；

通过第二生产方对所述第二任务进行封装，得到多个第二消息，各所述第二消息包括目的地信息；

根据所述目的地信息，通过所述消息队列将所述多个第二消息分配至多个第二消费方；以及

分别通过所述多个第二消费方对所述多个第二消息进行处理，得到所述任务处理结果。

6.根据权利要求2～5任一项所述的方法，其特征在于，所述异步任务清单表设置于关系型数据库，所述方法还包括：

通过分布式缓存对所述多个第二任务进行缓存；

在对所述第二任务进行封装之前，通过所述分布式缓存判断所述第二任务的节点占用状态。

7.根据权利要求1～5任一项所述的方法，其特征在于，所述消息队列为多条，分配所述第一任务与所述第二任务的消息队列相同或不同。

8.根据权利要求5所述的方法，其特征在于，各所述第一消息和/或所述第二消息还包括消息优先级，所述方法还包括：

在所述消息优先级小于预设阈值的情况下，转存所述第一消息和/或所述第二消息到数据库或文件***。

9.根据权利要求1所述的方法，其特征在于，在通过消息队列对所述第一任务进行分配之前，所述方法还包括：

对所述任务处理请求进行格式和类型的校验。

10.一种异步任务处理装置，其特征在于，所述装置包括：

生成模块，用于响应于任务处理请求，生成第一任务；

转换模块，用于通过消息队列对所述第一任务进行分配，并转换得到多个第二任务；以及

处理模块，用于通过所述消息队列对至少部分所述多个第二任务进行分配，并处理得到任务处理结果。

11.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个计算机程序，

其特征在于，所述一个或多个处理器执行所述一个或多个计算机程序以实现根据权利要求1～9中任一项所述方法的步骤。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现根据权利要求1～9中任一项所述方法的步骤。

13.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1～9中任一项所述方法的步骤。