CN113220435A - 任务处理方法及相关产品 - Google Patents

Abstract

本申请实施例提供一种任务处理方法及相关产品，该任务处理方法包括：服务端接收用户端上传的第一任务；创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。本申请实施例可以保证任务状态的一致性。

Description

任务处理方法及相关产品

技术领域

本申请涉及互联网技术领域，具体涉及一种任务处理方法及相关产品。

背景技术

在任务调度管理平台，涉及到许多类型的任务的处理，比如，图像、视频的处理任务。为了保证任务不被重复执行，一般采用生产者消费者模式的消息队列来实现任务的调度管理服务。如果生产者投递任务后出现宕机重启，则会导致调度管理服务的地址发生变化，无法将任务状态更新到生产者，进而无法保证任务状态的一致性。

发明内容

本申请实施例提供一种任务处理方法及相关产品，可以保证任务状态的一致性。

本申请实施例的第一方面提供了一种任务处理方法，所述方法应用于服务端，所述方法包括：

接收用户端上传的第一任务；

创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；

在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。

可选的，所述任务数据包括任务地址标签；所述更新持久化的所述任务数据之前，所述方法还包括：

在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，判断所述反馈消息的当前服务地址与所述任务地址标签是否相同；

若相同，向所述当前服务地址发送所述反馈消息。

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

若所述反馈消息的当前服务地址与所述任务地址标签不相同，通过注册中心获取所有消息订阅者的服务地址，确定所述所有消息订阅者的服务地址中哈希值最小的服务地址；

向所述哈希值最小的服务地址发送所述反馈消息。

可选的，所述接收用户端上传的第一任务，包括：

接收用户端上传的任务请求消息，所述任务请求消息携带令牌和所述第一任务；

所述接收用户端上传的第一任务之后，所述方法还包括：

校验所述令牌是否合法，判断所述令牌是否过期；

若所述令牌合法且未过期，执行所述创建并持久化所述第一任务的任务数据的步骤。

可选的，所述将包含所述任务数据的任务数据消息投递到第一消息队列之后，所述方法还包括：

返回所述第一任务的任务标识到所述用户端；

接收所述用户端发送的针对所述第一任务的查询消息，所述查询消息携带所述任务标识和所述令牌，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

校验所述令牌是否合法，判断所述令牌是否过期；

若所述令牌合法且未过期，响应所述查询消息返回查询结果到所述用户端。

可选的，所述更新持久化的所述任务数据之后，所述方法还包括：

根据所述任务数据确定所述第一任务的任务状态；

若所述第一任务的任务状态为“已失败”，采用异步方式删除用户端上传至文件存储系统的初始资源文件；或者，若所述第一任务的任务状态为“结果已获取”，采用异步方式删除用户端上传至文件存储系统的初始资源文件和/或处理后的资源文件，所述处理后的资源文件是所述初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务；又或者，

若所述第一任务的任务状态为“已成功”，并且所述资源文件在所述文件存储系统的存放时长达到设定阈值，删除所述初始资源文件和/或处理后的资源文件。

本申请实施例的第二方面提供了一种任务处理方法，所述方法应用于用户端，所述方法包括：

获取接口密钥，根据所述接口密钥获取带有有效期的令牌；

将所述令牌放入任务请求消息，向服务端发送所述任务请求消息，所述任务请求消息携带第一任务，所述任务请求消息用于请求所述服务端处理所述第一任务，所述服务端用于创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列；以及用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第一消息队列为生产者消费者模式的队列，所述第二消息队列为发布订阅模式的队列。

可选的，所述向服务端发送所述任务请求消息之后，所述方法还包括：

上传与所述第一任务对应的初始资源文件到文件存储系统。

可选的，所述向服务端发送所述任务请求消息之后，所述方法还包括：

获取所述服务端发送的所述第一任务的任务标识；

将所述任务标识和所述令牌放入查询消息，向所述服务端发送所述查询消息，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

在所述令牌合法且未过期的情况下，接收所述服务端针对所述查询消息返回的查询结果。

可选的，所述接收所述服务端针对所述查询消息返回的查询结果之后，所述方法还包括：

若所述查询结果包括任务状态为“已成功”，将所述任务标识和所述令牌放入文件下载请求消息，向所述服务端发送所述文件下载请求消息；

在所述令牌合法且未过期的情况下，从文件存储系统下载处理后的资源文件，所述处理后的资源文件是用户端上传至所述文件存储系统的初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务。

本申请实施例的第三方面提供了一种任务处理装置，所述装置应用于服务端，所述装置包括：

接收单元，用于接收用户端上传的第一任务；

创建单元，用于创建并持久化所述第一任务的任务数据；

任务投递单元，用于将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；

更新单元，用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。

本申请实施例的第四方面提供了一种任务处理装置，所述装置应用于用户端，所述装置包括：

获取单元，用于获取接口密钥，根据所述接口密钥获取带有有效期的令牌；

任务请求单元，用于将所述令牌放入任务请求消息，向服务端发送所述任务请求消息，所述任务请求消息携带第一任务，所述任务请求消息用于请求所述服务端处理所述第一任务。

本申请实施例的第五方面提供了一种服务器，包括处理器和存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如本申请实施例第一方面中的步骤指令。

本申请实施例的第六方面提供了一种电子设备，包括处理器和存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如本申请实施例第二方面中的步骤指令。

本申请实施例的第七方面提供了一种计算机可读存储介质，其中，上述计算机可读存储介质用于存储计算机程序，上述计算机程序使得计算机执行如本申请实施例第一方面或第二方面中所描述的部分或全部步骤。

本申请实施例的第八方面提供了一种计算机程序产品，其中，上述计算机程序产品包括计算机程序，上述计算机程序被计算机执行时使得上述计算机执行如本申请实施例第一方面或第二方面中所描述的部分或全部步骤。该计算机程序产品可以为一个软件安装包。

本申请实施例中，服务端接收用户端上传的第一任务；创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。本申请实施例的服务端的任务提交使用第一消息队列实现，第一任务的结果反馈使用第二消息队列实现，保证任务状态和任务执行进度可追溯，采用双主题消息队列(生产者消费者模式的队列和发布订阅模式的队列)，既保证了第一任务不被重复执行，又保证了第一任务的执行反馈消息可以反馈到订阅者，保证任务状态的一致性。

附图说明

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

图1是本申请实施例提供的一种用户端和服务端的通信连接架构图；

图2是本申请实施例提供的一种任务处理方法的流程示意图；

图3是本申请实施例提供的一种生产者消费者模式的示意图；

图4是本申请实施例提供的一种发布订阅模式的示意图；

图5是本申请实施例提供的另一种任务处理方法的流程示意图；

图6是本申请实施例提供的另一种任务处理方法的流程示意图；

图7是本申请实施例提供的另一种任务处理方法的流程示意图；

图8是本申请实施例提供的一种任务处理装置的结构示意图；

图9是本申请实施例提供的一种服务器的结构示意图；

图10是本申请实施例提供的另一种任务处理装置的结构示意图；

图11是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。

本申请实施例所涉及到的电子设备可以包括具有运算能力和通信能力的设备，比如，图像处理前端设备、手机、平板、个人电脑等。图像处理前端设备可以包括人脸识别装置，比如人脸识别门禁、人脸识别考勤机等。个人电脑也可以称为用户电脑，可以包括台式电脑、笔记本电脑等。为方便描述，上面提到的设备统称为电子设备。用户端是为用户提供本地服务的程序，用户端可以运行在电子设备上。

本申请实施例所涉及到的服务器可以是微服务器集群中的服务器，服务端可以运行在服务器上。服务端是为用户端服务的，服务的内容包括向用户端提供服务(比如，人脸识别服务、视频处理服务、语音处理服务等)，保存用户端数据等。

请参阅图1，图1是本申请实施例提供的一种用户端和服务端的通信连接架构图。如图1所示，服务端100可以与至少一个用户端101进行通信连接。用户端可以直接与服务端建立通信连接，也可以通过其他设备与服务端建立通信连接。服务端可以提供多种类型的服务，客户端可以向服务端发送服务请求。服务端接收用户端上传的任务后，服务端的生产者创建并持久化该任务的任务数据，生产者将该任务数据投递到生产者消费者模式的队列(第一消息队列)，服务端的消费者监听到有任务进入该队列，则开始处理该任务，处理完后将该任务的处理结果投递到发布订阅模式的队列(第二消息队列)，由于生产者可以是订阅者，在处理结果投递到发布订阅模式的队列后，生产者可以订阅到处理结果，更新持久化的任务数据。任务数据持久化后，可以保证消息队列的任务数据不会丢失，使得消费者能够处理该消息队列中的任务，保证消息队列中的数据到服务的可达性。此外，基于任务数据的任务状态也能够保证实时更新。

服务端可以有很多个服务，生产者、消费者、发布者、订阅者均是某一个服务(比如服务A)在任务调度的业务上承担的某一个角色，是一个抽象的概念。比如，生产者可以是服务A中用来做将消息投递到第一消息队列的角色，消费者可以是服务A中用来做从第一消息队列中取消息进行处理的角色，发布者可以是服务A中用来将任务处理结果发布到第二消息队列的角色，订阅者可以是服务A中用来从第二消息队列中取消息的角色。生产者、消费者、发布者、订阅者在某一个时间段都可以对应服务端的一个功能模块(功能模块可以通过程序代码来实现)，而这个功能模块在不同时间段，可以由不同的角色扮演，因为这个功能模块不仅要做任务调度的业务，还可以做其他的调度相关的业务。比如，将消息投递到消息队列的功能模块，在任务处理的业务里面，是将任务消息投递到消息队列，由生产者扮演这个角色；在任务结果通知的业务里面，是将任务的执行反馈消息投递到消息队列，由发布者扮演这个角色。

数据持久化，是将内存中的数据模型转换为存储模型，以及将存储模型转换为内存中的数据模型的统称。比如，可以将处理过程中的数据存放在硬盘或者数据库中。

请参阅图2，图2是本申请实施例提供的一种任务处理方法的流程示意图。该方法应用于图1所示的服务端，如图2所示，该任务处理方法可以包括如下步骤。

201，服务端接收用户端上传的第一任务。第一任务可以是用户端上传的一个任务，也可以是用户端上传的多个任务中的一个。

202，服务端创建并持久化第一任务的任务数据，将包含任务数据的任务数据消息投递到第一消息队列，第一消息队列为生产者消费者模式的队列。

本申请实施例中，第一任务可以是图像处理任务、视频处理任务、音频处理任务、语音处理任务等处理耗时较久的任务。如果不采用生产者消费者模式的消息队列处理任务，则用户端在调用上传任务的接口的时候需要长时间的等待结果。

消息队列，是在消息的传输过程中保存消息的容器。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。本申请实施例中的任务数据可以理解为消息。

生产者消费者模式的队列，也可以称为生产消费模式的队列。生产者消费者模式：需要使用到同步，以及线程，属于多并发行列，可以支持多个生产者同时生产多个任务数据，也可以支持多个消费者同时处理任务。请参阅图3，图3是本申请实施例提供的一种生产者消费者模式的示意图。如图3所示，生产者消费者模式中产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。第一消息队列相当于一个缓冲区，处于生产者和消费者之间，作为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据。

生产者消费者模式的队列具有解耦、支持并发和支持忙闲不均的功能。

解耦：假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖(也就是耦合)。将来如果消费者的代码发生变化，可能会影响到生产者。如果采用生产者消费者模式的队列，两者都依赖于第一消息队列，两者之间不直接依赖，耦合也就相应降低了。

支持并发：如果采用生产者直接调用消费者的某个方法，还有另一个弊端。由于函数调用是同步的(或者叫阻塞的)，在消费者的方法没有返回结果之前，生产者只能一直等待。万一消费者处理数据很慢(比如，视频文件的处理)，生产者就会白白浪费时间。本申请实施例使用了生产者消费者模式的队列之后，生产者和消费者可以是两个独立的并发主体(常见并发类型有进程和线程两种)。生产者把生产出来的任务数据投递到第一消息队列，就可以再去生产下一个任务数据，生产者不用依赖消费者的处理速度。

支持忙闲不均：如果生产者生产数据的速度时快时慢，生产者消费者模式的队列的好处就体现出来了。当生产者生产数据较快的时候，消费者来不及处理，未处理的数据可以暂时存在生产者消费者模式的队列中。等消费者处理完当前数据后，继续从生产者消费者模式的队列中取出数据处理。

服务端的生产者创建第一任务的任务数据(即，生产者生产数据)，生产者还可以持久化第一任务的任务数据。生产者将包含任务数据的任务数据消息投递到第一消息队列队尾，第一消息队列为生产者消费者模式的队列。消费者可以从第一消息队列的队头取出任务数据进行处理。如果生产者将包含任务数据的任务数据消息投递到第一消息队列之前，第一消息队列为空，第一消息队列没有元素，则任务数据投递在第一消息队列时，处于第一消息队列的队头。

任务数据可以包括任务标签、任务状态、任务发布的地址，还可以包括一些其他相关的参数信息。任务数据持久化，后续可以根据任务数据更新任务的状态，可以跟踪任务的进度。

持久化数据，可以理解为把数据存在数据库中，只有生产者跟数据库有交互，消费者不跟数据库交互。

当消费者处理完任务数据消息后，可以将第一任务的执行反馈消息放入第二消息队列。第一任务的执行反馈消息可以包括“执行成功”或“执行失败”。

可选的，步骤201可以包括如下步骤：

服务端接收用户端上传的任务请求消息，任务请求消息携带令牌和第一任务。

在执行步骤201之后，还可以执行如下步骤：

服务端校验令牌是否合法，判断令牌是否过期；若令牌合法且未过期，执行步骤202。

本申请实施例中，令牌，也可以称为token。token在计算机身份认证中是令牌(临时)的意思，一般作为访问、系统登录使用。令牌一般用来代替密钥来访问相关资源。令牌一般是有一定期限的，在期限内使用则有效，如果超过期限，则被认为无效。用户端可以先获取接口密钥，然后携带密钥信息调用服务端的令牌生成接口获取带有有效期的令牌。用户端获取令牌后，可以将令牌放入任务请求消息，然后调用任务提交的接口，向服务端提交第一任务。服务端会校验令牌的合法性以及是否过期，如果令牌合法且未过期，则执行后续的步骤，否则，服务端向用户端返回包含令牌不合法或者令牌已过期的消息。

本申请实施例在任务请求消息中通过令牌进行验证，可以保证数据传输安全，由于令牌可以携带大量的必要数据，令牌由服务端生成，由服务端校验，提高数据访问安全性的同时很好的解决了用户端和服务端不同步的问题。

可选的，在步骤202服务端将包含任务数据的任务数据消息投递到第一消息队列之后，还可以执行如下步骤：

(11)服务端返回第一任务的任务标识到用户端；

(12)服务端接收用户端发送的针对第一任务的查询消息，查询消息携带任务标识和令牌，查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

(13)服务端校验令牌是否合法，判断令牌是否过期；

(14)若令牌合法且未过期，服务端响应查询消息返回查询结果到用户端。

本申请实施例中，服务端返回第一任务的任务标识(如任务ID)到用户端，用户端可以根据第一任务的任务ID查询第一任务的执行进度和状态。用户端在发送针对第一任务的查询消息时，将令牌加入查询消息，服务端可以进行令牌校验，可以保证服务端和客户端之间的数据传输安全。

其中，任务执行进度查询消息用于查询第一任务的执行进度。第一任务的执行进度可以包括“已创建”、“已投递”和“已确认”中的任一种。服务端的生产者创建第一任务的任务数据时，第一任务的执行进度为“已创建”；服务端的生产者将第一任务的任务数据投递到第一消息队列时，第一任务的执行进度为“已投递”；服务端的消费者从第一消息队列取第一任务的任务数据时，第一任务的执行进度为“已确认”。

任务状态查询消息用于查询第一任务的任务状态。第一任务的任务状态可以包括“已失败”、“已成功”和“结果已获取”中的任一种。服务端的消费者处理任务数据消息，即执行第一任务后，得到第一任务的执行结果为执行失败，则第一任务的任务状态为“已失败”；服务端的消费者执行第一任务后，得到第一任务的执行结果为执行成功，则第一任务的任务状态为“执行成功”；当用户端查询到第一任务的执行结果为执行成功，从文件存储系统成功下载处理后的资源文件(处理后的资源文件是用户端上传至文件存储系统的初始资源文件经过第一任务处理后得到的)后，则第一任务的任务状态为“结果已获取”。

203，服务端在监听到第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的任务数据，第二消息队列为发布订阅模式的队列。

本申请实施例中，发布订阅模式，也可以称为发布者订阅者模式。

请参阅图4，图4是本申请实施例提供的一种发布订阅模式的示意图。如图4所示，发布订阅模式中，消息的发送方叫做发布者(publishers)，消息的接收方叫做订阅者(Subscriber)。发布者和订阅者不知道对方的存在，需要一个第三方组件，即第二消息队列，第二消息队列将订阅者和发布者串联起来。

本申请实施例中，发布订阅模式是一种消息范式，消息的发送者(称为发布者)不会将消息直接发送给特定的接收者(称为订阅者)，而是将消息投递到第二消息队列，让订阅该消息主题的订阅者获取到。

订阅者可以监听第二消息队列，当第二消息队列进来了符合订阅者的订阅的消息主题的消息时，订阅者可以从该第二消息队列中拿到该消息。

当消费者处理完任务数据消息后，将第一任务的执行反馈消息放入第二消息队列后，订阅者通过监听该第二消息队列，使该反馈消息从第二消息队列中出列，实现从该第二消息队列中获取该反馈消息。由于采用消息队列来实现发布订阅模式，进入第二消息队列的反馈消息只会被执行一次订阅服务(可以同时有一个或多个订阅者订阅同一个消息主题)，保证同一个反馈消息不会被同一个订阅者重复接收。

其中，第一消息队列的消费者可以是第二消息队列的发布者，第二消息队列的订阅者可以是第一消息队列的生产者。第一消息队列的生产者可以订阅与第一任务的处理结果相关的主题，从而保证第一任务的任务数据的生产者能够及时获得该第一任务的处理结果，从而实现任务状态的同步和结果反馈，保证任务状态的一致性。

本申请实施例的任务处理方法可以应用在微服务架构。微服务架构是一项在云中部署应用和服务的新技术。微服务可以在自己的程序中运行，并通过轻量级设备与超文本传输协议(HyperText Transfer Protocol，HTTP)型的应用程序编程接口(ApplicationProgramming Interface，API)进行沟通。微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

本申请实施例的用户端可以通过微服务与服务端通信，用户端可以调用接口，通过HTTP方式与服务端通信。服务端可以提供多个类型的服务(微服务)，比如，生产者、消费者组成的生产消费服务，发布者、订阅者组成的发布订阅服务。服务端中可以包括多个功能模块，比如第一功能模块在生产消费服务中充当生产者的角色，在发布订阅服务中充当订阅者的角色。比如，第二功能模块在生产消费服务中充当消费者的角色，在发布订阅服务中充当发布者的角色。生产消费、发布订阅是服务端的功能。

本申请实施例的服务端的任务提交使用第一消息队列实现，第一任务的结果反馈使用第二消息队列实现，保证任务状态和任务执行进度可追溯，采用双主题消息队列(生产者消费者模式的队列和发布订阅模式的队列)，既保证了第一任务不被重复执行，又保证了第一任务的执行反馈消息可以反馈到订阅者，保证任务状态的一致性，还可以实现任务整个执行的闭环和状态的维护，通过持久化机制保证消息队列到服务的可达性，实现流量高峰期的削峰和流控。

请参阅图5，图5是本申请实施例提供的另一种任务处理方法的流程示意图。图5是在图2的基础上进一步优化得到的。如图5所示，该任务处理方法可以包括如下步骤。

501，服务端接收用户端上传的第一任务。

502，服务端创建并持久化第一任务的任务数据，将包含任务数据的任务数据消息投递到第一消息队列，第一消息队列为生产者消费者模式的队列。

503，服务端在监听到第一任务的执行反馈消息进入第二消息队列的情况下，判断反馈消息的当前服务地址与任务地址标签是否相同，第二消息队列为发布订阅模式的队列。

本申请实施例中，第一任务的任务数据可以包含任务地址标签。服务端根据生产者创建的第一任务的任务数据确定任务地址标签。任务地址标签是服务端打的标签。

反馈消息的当前服务地址可以是当前的生产消费服务的地址，也即生产者消费者模式的队列(第一消息队列)的生产者的地址。

服务端有两个服务：生产消费服务和发布订阅服务。当前服务是生产消费服务。生产消费服务的地址是生产者的地址，发布订阅服务的地址是订阅者的地址。生产者的地址也可以称为生产者的服务地址，订阅者的地址，也可以称为订阅者的服务地址。

生产者在向第一消息队列投递第一任务的任务数据后，服务端会为生产者生成的第一任务打上地址标签，即任务地址标签。如果第一任务在消费者执行的过程，生产者宕机重启，导致容器环境下生产消费服务的地址(比如，IP地址)发生变化，则当前的生产消费服务的地址发生变化，当前的生产消费服务的地址与任务地址标签不相同。如果第一任务在消费者执行的过程，生产者未出现异常，则当前的生产消费服务的地址不会发生变化，当前的生产消费服务的地址与任务地址标签相同。

504，若相同，服务端向当前服务地址发送反馈消息。

505，服务端更新持久化的任务数据。

其中，步骤501、502和505可以参见图2所示的步骤201至步骤203的具体实施，此处不再赘述。

可选的，图5的方法还可以包括如下步骤：

(21)若反馈消息的当前服务地址与任务地址标签不相同，服务端通过注册中心获取所有消息订阅者的服务地址，确定所有消息订阅者的服务地址中哈希值最小的服务地址；

(22)服务端向哈希值最小的服务地址发送反馈消息。

本申请实施例中，注册中心有所有消息订阅者的服务地址。生产者消费者模式的生产者也可以同时是订阅发布订阅模式的订阅者，可以订阅发布订阅模式的服务地址。本申请实施例可以在当前服务地址(当前的生产消费服务的地址)与任务地址标签不相同的情况下，通过最小哈希算法确定哈希值最小的服务地址，服务端向哈希值最小的服务地址发送反馈消息。保证第二消息队列中的反馈消息一定会被处理，也只会被一个服务处理，避免出现第二消息队列中的反馈消息不能被处理导致任务状态不一致的情况。

哈希最小的订阅者不一定是原订阅者，如果是其他订阅者收到反馈消息后，根据反馈消息携带的任务标签，其他订阅者收到消息后可以在任务标签对应的任务数据中更新该任务标签对应的任务的状态，从而保证任务状态一致。

请参阅图6，图6是本申请实施例提供的另一种任务处理方法的流程示意图。图6是在图2的基础上进一步优化得到的。如图6所示，该任务处理方法可以包括如下步骤。

601，服务端接收用户端上传的第一任务。

602，服务端创建并持久化第一任务的任务数据，将包含任务数据的任务数据消息投递到第一消息队列，第一消息队列为生产者消费者模式的队列。

603，服务端在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的任务数据，第二消息队列为发布订阅模式的队列。

本申请实施例中的步骤601至步骤603的具体实施可以参见图2所示的步骤201至步骤203的具体实施，此处不再赘述。

604，服务端根据任务数据确定第一任务的任务状态。

605，若第一任务的任务状态为“已失败”，采用异步方式删除用户端上传至文件存储系统的初始资源文件；或者，若所述第一任务的任务状态为“结果已获取”，服务端采用异步方式删除用户端上传至文件存储系统的初始资源文件和/或处理后的资源文件，处理后的资源文件是初始资源文件经过第一任务处理后得到的，第一任务包括针对初始资源文件的处理任务。又或者，

606，若第一任务的任务状态为“已成功”，并且处理后的资源文件在文件存储系统的存放时长达到设定阈值，服务端删除初始资源文件和/或处理后的资源文件。

本申请实施例中，使用任务状态更新监听和定时扫描结合的方式实现资源文件的清理和隐私保护。步骤604可以在步骤603之后立即执行，可以及时更新任务状态。

如果第一任务的任务状态为“已失败”，消费者处理失败并没有产生处理后的资源文件，为了清理文件存储系统的存储空间，服务端可以删除该初始资源文件。

若第一任务的任务状态为“结果已获取”，则消费者处理后的资源文件已经被用户端下载，用户端也没有重复下载的需求，为了清理文件存储系统的存储空间，则服务端可以删除该初始资源文件和处理后的资源文件中的至少一个。由于资源文件删除的实时性要求不高，采用异步方式删除，无需立即删除，可以在服务端繁忙时降低服务端的负担。

若第一任务的任务状态为“已成功”，并且处理后的资源文件在文件存储系统的存放时长达到设定阈值，此时用户端虽然知道该任务的任务状态为“已成功”，但由于某些原因没有向服务端下载处理后的资源文件，可能后续仍然有下载该处理后的资源文件的需求，为了清理文件存储系统的存储空间，当用户端长时间未下载该处理后的资源文件，则服务端可以删除初始资源文件，保留处理后的资源文件，提供后续客户端下载的可能。可选的，若第一任务的任务状态为“已成功”，并且处理后的资源文件在文件存储系统的存放时长达到设定阈值，服务端也可以将初始资源文件和处理后的资源文件同时删除，进一步清理文件存储系统的存储空间。可选的，若第一任务的任务状态为“已成功”，并且处理后的资源文件在文件存储系统的存放时长达到设定阈值，服务端也可以将处理后的资源文件删除，保留原始资源文件，可以在客户端后续继续发起针对该原始资源文件的任务处理请求时，无需重复上传该原始资源文件到文件存储系统。

其中，资源文件可以是视频文件、图片文件、音频文件等占用存储空间较大的文件。

本申请实施例的服务端的任务提交使用第一消息队列实现，第一任务的结果反馈使用第二消息队列实现，保证任务状态和任务执行进度可追溯，采用双主题消息队列(生产者消费者模式的队列和发布订阅模式的队列)，既保证了第一任务不被重复执行，又保证了第一任务的执行反馈消息可以反馈到订阅者，保证任务状态的一致性，还可以实现任务整个执行的闭环和状态的维护，通过持久化机制保证消息队列到服务的可达性，实现流量高峰期的削峰和流控。还可以使用任务状态更新监听和定时扫描结合的方式实现资源文件的清理和隐私保护。

请参阅图7，图7是本申请实施例提供的另一种任务处理方法的流程示意图。该方法应用于用户端，如图7所示，该方法包括如下步骤。

701，用户端获取接口密钥，根据接口密钥获取带有有效期的令牌。

本申请实施例中，用户端获取接口密钥后，可以携带接口密钥调用令牌生成接口获取带有有效期的令牌。令牌生成接口是服务端提供的接口，令牌由服务端生成，令牌的生成和校验统一由服务端管控，他人无法伪造令牌，有利于提高数据访问的安全性。

702，用户端将令牌放入任务请求消息，向服务端发送任务请求消息，任务请求消息携带第一任务，任务请求消息用于请求服务端处理第一任务。

其中，所述服务端用于创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列；以及用于在监听到第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的任务数据，第一消息队列为生产者消费者模式的队列，第二消息队列为发布订阅模式的队列。

本申请实施例中，用户端和服务端可以通过超文本传输协议HTTP进行通信，任务请求消息可以是HTTP消息。服务端可以校验任务请求消息中的令牌的合法性和有效期，如果令牌合法且未过期，服务端开始处理第一任务。

本申请实施例在任务请求消息中通过令牌进行验证，可以保证数据传输安全，令牌由服务端生成，由服务端校验，解决了用户端和服务端不同步的问题。

可选的，在步骤702用户端向服务端发送所述任务请求消息之后，还可以包括如下步骤：

用户端上传与所述第一任务对应的初始资源文件到文件存储系统。

本申请实施例中，第一任务可以包括针对初始资源文件的处理任务。文件存储系统可以包括分布式文件存储系统。服务端的消费者在执行第一任务时，可以对第一任务对应的初始资源文件进行处理。资源文件可以包括视频文件、图片文件、音频文件等占用存储空间较大的文件中的任一种。

可选的，用户端向服务端发送所述任务请求消息之后，所述方法还包括：

(31)用户端获取服务端发送的第一任务的任务标识；

(32)用户端将任务标识和令牌放入查询消息，向服务端发送查询消息，查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

(33)用户端在令牌合法且未过期的情况下，接收服务端针对查询消息返回的查询结果。

本申请实施例中，服务端返回第一任务的任务标识后，用户端可以根据第一任务的任务标识随时查询任务执行进度和任务状态。本申请实施例的用户端与服务端可以通过令牌和第一任务的任务标识进行多次数据交互，实现了任务异步执行。与采用websocket全双工方式相比，服务端无需主动向用户端推送任务执行状态的通知消息，降低了服务端的开发难度和用户端的使用难度(服务端不需要同时支持http和websocket协议，用户端不需要根据不同的接口改变请求协议)。

可选的，用户端接收所述服务端针对所述查询消息返回的查询结果之后，所述方法还包括：

(41)若查询结果包括任务状态为“已成功”，用户端将任务标识和令牌放入文件下载请求消息，向服务端发送文件下载请求消息；

(42)在令牌合法且未过期的情况下，用户端从文件存储系统下载处理后的资源文件，处理后的资源文件是用户端上传至文件存储系统的初始资源文件经过第一任务处理后得到的，第一任务包括针对初始资源文件的处理任务。

本申请实施例中，如果用户端查询到第一任务的任务状态为“已成功”，用户端将任务标识和令牌放入文件下载请求消息，向服务端发送文件下载请求消息。用户端可以根据第一任务的任务标识和令牌从文件存储系统下载处理后的资源文件。由用户端主动发起资源文件的下载，无需服务端执行文件下载，降低服务端的开发难度。由于下载请求是用户端主动发起的，是征得用户同意的情况下下载了，充分保证了用户数据的隐私。

可选的，若下载失败，用户端可以继续向服务端发送文件下载请求消息(用户端重试下载)，当重试下载的次数达到预设次数或者所述处理后的资源文件在所述文件存储系统存储的时长达到设定阈值，用户端停止向服务端发送文件下载请求消息(用户端停止下载)。

本申请实施例中，可以根据文件下载请求消息的任务执行结果确定下载失败的原因，例如通过任务执行结果包含的状态码和错误消息找到下载失败的原因，使得用户可以根据错误消息清晰了解到请求执行失败的原因。下载失败的原因可以包括网络原因(错误消息可以包括：网络故障)、未找处理后的资源文件(错误消息可以包括：资源文件被清理)，即文件存储系统的处理后的资源文件已被清理(比如，服务端确定任务状态为“已失败”或“结果已获取”，服务端会采用异步方式删除处理后的资源文件)。

如果下载失败的原因是网络原因，则用户端可以继续向服务端发送文件下载请求消息；如果下载失败的原因是未找处理后的资源文件，则表明文件存储系统的处理后的资源文件已被服务端清理，用户端可以不用重复向服务端发送文件下载请求消息。

一般而言，若查询结果包括任务状态为“已失败”和“结果已获取”，用户端不会向服务端发送文件下载请求消息。

本申请实施例考虑了任务执行失败或者文件下载失败时资源文件的清理和用户重试下载的情况，可以实现资源文件的清理和隐私保护。

在实际使用场景中，任务处理方法的应用于用户端和服务端，该任务处理方法的具体流程可以包括如下步骤。

1、用户端获取接口密钥，然后携带密钥信息调用令牌生成接口获取带有有效期的令牌token，生成的令牌由用户端自行保存，过有效期后通过密钥重新刷新即可。

2、用户端获取到token后，将token放在http请求头，然后调用任务提交的接口，服务端校验令牌的合法性以及是否过期，然后服务端将创建并持久化任务元数据，用户端上传资源文件到文件存储系统，投递任务数据消息到消息队列A，最后返回任务id到用户端。消息队列A可以是Redis消息队列，任务元数据是任务的初始数据，可以包括任务标签、任务初始状态、任务发布的地址等。

3、用户端获取到任务id后，将token放在http请求头，任务id作为请求参数，可以查询任务的执行进度和状态。

4、当调度服务的消息队列B监听器监听到任务执行反馈消息后，采用任务标签+最小哈希算法更新持久化的任务数据，若任务失败，服务端会异步的方式删除用户端上传的资源文件。消息队列B可以是Redis消息队列。

5、用户端查询到任务执行成功后，将token放在http请求头，任务id作为请求参数，调用处理后的资源文件下载的接口，如果下载成功，任务状态会被标记为“结果已获取”，同时服务端将会异步的删除用户端上传的资源文件；如果下载失败，用户端可以一直重试下载，直到资源文件在文件存储系统存放的时长达到服务端配置的阈值。

本申请实施例的令牌可以是基于加密算法(比如，HMACSHA256算法)加密的生成的令牌(令牌可以是JsonWebToken)，可验证请求的合法性和有效性。基于Redis的消息队列可实现消息的异步处理和削峰限流以及任务调度。本申请实施例使用双队列，采用生产者消费者模式的队列实现任务的投递，采用发布订阅模式的队列实现任务状态同步和结果反馈。还可以结合状态机思想和事件监听机制实现任务执行状态的更新，使用任务标签+最小哈希算法保证消息只被执行一次，保证状态的一致性。还可以通过持久化任务详情数据，异步清理资源文件，保证用户数据的隐私。

上述主要从方法侧执行过程的角度对本申请实施例的方案进行了介绍。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所提供的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对服务器和电子设备进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

请参阅图8，图8是本申请实施例提供的一种任务处理装置的结构示意图，该任务处理装置800应用于服务端，该任务处理装置800可以包括接收单元801、创建单元802、任务投递单元803、更新单元804，其中：

接收单元801，用于接收用户端上传的第一任务；

创建单元802，用于创建并持久化所述第一任务的任务数据；

任务投递单元803，用于将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；

更新单元804，用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。

可选的，所述任务数据包括任务地址标签；该任务处理装置800可以包括判断单元805和第一发送单元806。

判断单元805，用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，判断所述反馈消息的当前服务地址与所述任务地址标签是否相同；

第一发送单元806，用于在所述判断单元805判断所述反馈消息的当前服务地址与所述任务地址标签相同的情况下，向所述当前服务地址发送所述反馈消息。

可选的，该任务处理装置800可以包括确定单元807。

确定单元807，用于在所述判断单元805判断所述反馈消息的当前服务地址与所述任务地址标签不相同的情况下，通过注册中心获取所有消息订阅者的服务地址，确定所述所有消息订阅者的服务地址中哈希值最小的服务地址；

所述第一发送单元806，还用于向所述哈希值最小的服务地址发送所述反馈消息。

可选的，该任务处理装置800可以包括校验单元808。

所述接收单元801接收用户端上传的第一任务，包括：接收用户端上传的任务请求消息，所述任务请求消息携带令牌和所述第一任务；

校验单元808，用于在所述接收单元801接收用户端上传的第一任务之后，校验所述令牌是否合法，判断所述令牌是否过期；

所述创建单元802，还用于在所述校验单元808校验所述令牌合法且未过期的情况下，创建并持久化所述第一任务的任务数据。

可选的，该任务处理装置800可以包括返回单元809。

返回单元809，用于在所述任务投递单元803将包含所述任务数据的任务数据消息投递到第一消息队列之后，返回所述第一任务的任务标识到所述用户端；

所述接收单元801，还用于接收所述用户端发送的针对所述第一任务的查询消息，所述查询消息携带所述任务标识和所述令牌，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

所述校验单元808，还用于校验所述令牌是否合法，判断所述令牌是否过期；

所述返回单元809，还用于在所述校验单元808校验所述令牌合法且未过期的情况下，响应所述查询消息返回查询结果到所述用户端。

可选的，该任务处理装置800可以包括删除单元810。

所述确定单元807，还用于在所述更新单元804更新持久化的所述任务数据之后，根据所述任务数据确定所述第一任务的任务状态；

删除单元810，用于在所述第一任务的任务状态为“已失败”的情况下，采用异步方式删除用户端上传至文件存储系统的初始资源文件；或者，在所述第一任务的任务状态为所述第一任务的任务状态为“结果已获取”的情况下，采用异步方式删除用户端上传至文件存储系统的初始资源文件和/或处理后的资源文件，所述处理后的资源文件是用户端上传至文件存储系统的初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务；

所述删除单元810，还用于在所述第一任务的任务状态为“已成功”，并且所述处理后的资源文件在所述文件存储系统的存放时长达到设定阈值的情况下，删除所述初始资源文件和/或处理后的资源文件。

其中，本申请实施例中的接收单元801、返回单元809可以是服务器的输入输出装置，创建单元802、任务投递单元803、更新单元804、判断单元805、第一发送单元806、校验单元808、删除单元810可以是服务器的处理器。

本申请实施例中，第一任务的任务提交使用第一消息队列实现，第一任务的结果反馈使用第二消息队列实现，保证任务状态和任务执行进度可追溯，采用双主题消息队列(生产者消费者模式的队列和发布订阅模式的队列)，既保证了第一任务不被重复执行，又保证了第一任务的执行反馈消息可以反馈到订阅者，保证任务状态的一致性，还可以实现任务整个执行的闭环和状态的维护，通过持久化机制保证消息队列到服务的可达性，实现流量高峰期的削峰和流控。

请参阅图9，图9是本申请实施例提供的一种服务器的结构示意图，如图9所示，该服务器900包括处理器901和存储器902，处理器901、存储器902可以通过通信总线903相互连接。通信总线903可以是外设部件互连标准(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，简称EISA)总线等。通信总线903可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器902用于存储计算机程序，计算机程序包括程序指令，处理器901被配置用于调用程序指令，上述程序包括用于执行图2～图6中的方法。

处理器901可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。

存储器902可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

该服务器900还可以包括输入输出装置904，输入输出装置904可以包括射频电路、天线等输入输出装置。

本申请实施例中，第一任务的任务提交使用第一消息队列实现，第一任务的结果反馈使用第二消息队列实现，保证任务状态和任务执行进度可追溯，采用双主题消息队列(生产者消费者模式的队列和发布订阅模式的队列)，既保证了第一任务不被重复执行，又保证了第一任务的执行反馈消息可以反馈到订阅者，保证任务状态的一致性，还可以实现任务整个执行的闭环和状态的维护，通过持久化机制保证消息队列到服务的可达性，实现流量高峰期的削峰和流控。

请参阅图10，图10是本申请实施例提供的另一种任务处理装置的结构示意图，该任务处理装置1000应用于用户端，该任务处理装置1000可以包括获取单元1001和任务请求单元1002、其中：

获取单元1001，用于获取接口密钥，根据所述接口密钥获取带有有效期的令牌；

任务请求单元1002，用于将所述令牌放入任务请求消息，向服务端发送所述任务请求消息，所述任务请求消息携带第一任务，所述任务请求消息用于请求所述服务端处理所述第一任务，所述服务端用于创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列；以及用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第一消息队列为生产者消费者模式的队列，所述第二消息队列为发布订阅模式的队列。

可选的，该任务处理装置1000还可以包括上传单元1003。

上传单元1003，用于在所述任务请求单元1002向服务端发送所述任务请求消息之后，上传与所述第一任务对应的初始资源文件到文件存储系统。

可选的，该任务处理装置1000还可以包括第二发送单元1004。

所述获取单元1001，还用于获取所述服务端发送的所述第一任务的任务标识；

第二发送单元1004，用于将所述任务标识和所述令牌放入查询消息，向所述服务端发送所述查询消息，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

所述获取单元1001，还用于在所述令牌合法且未过期的情况下，接收所述服务端针对所述查询消息返回的查询结果。

可选的，该任务处理装置1000还可以包括下载单元1005。

所述第二发送单元1004，还用于在所述查询结果包括任务状态为“已成功”的情况下，将所述任务标识和所述令牌放入文件下载请求消息，向所述服务端发送所述文件下载请求消息；

下载单元1005，还用于在在所述令牌合法且未过期的情况下，从文件存储系统下载处理后的资源文件，所述处理后的资源文件是用户端上传至所述文件存储系统的初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务。

可选的，所述第二发送单元1004，还用于在所述下载单元1005下载失败的情况下，继续向服务端发送文件下载请求消息，当重试下载的次数达到预设次数或者所述处理后的资源文件在所述文件存储系统存储的时长达到设定阈值，停止向服务端发送文件下载请求消息。

其中，本申请实施例中的获取单元1001、上传单元1003、第二发送单元1004可以是电子设备的输入输出装置，任务请求单元1002、下载单元1005可以是电子设备的处理器。

本申请实施例在任务请求消息中通过令牌进行验证，可以保证数据传输安全，令牌由服务端生成，由服务端校验，解决了用户端和服务端不同步的问题。

请参阅图11，图11是本申请实施例提供的一种电子设备的结构示意图，如图11所示，该电子设备1100包括处理器1101和存储器1102，处理器1101、存储器1102可以通过通信总线1103相互连接。通信总线1103可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。通信总线1103可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器1102用于存储计算机程序，计算机程序包括程序指令，处理器1101被配置用于调用程序指令，上述程序包括用于执行图2或3所示的方法。

处理器1101可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。

存储器1102可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

该电子设备1100还可以包括输入输出装置1104，输入输出装置1104可以包括键盘、鼠标、麦克风等输入装置，还可以包括显示屏、扬声器等输出装置，还可以包括射频电路、天线等输入输出装置。

本申请实施例中，本申请实施例在任务请求消息中通过令牌进行验证，可以保证数据传输安全，令牌由服务端生成，由服务端校验，解决了用户端和服务端不同步的问题。

本申请实施例还提供一种计算机可读存储介质，其中，该计算机可读存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任何一种任务处理方法的部分或全部步骤。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在申请明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

所述集成的单元如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器、随机存取器、磁盘或光盘等。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种任务处理方法，其特征在于，所述方法应用于服务端，所述方法包括：

接收用户端上传的第一任务；

创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；

在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。

2.根据权利要求1所述的方法，其特征在于，所述任务数据包括任务地址标签；所述更新持久化的所述任务数据之前，所述方法还包括：

在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，判断所述反馈消息的当前服务地址与所述任务地址标签是否相同；

若相同，向所述当前服务地址发送所述反馈消息。

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

若所述反馈消息的当前服务地址与所述任务地址标签不相同，通过注册中心获取所有消息订阅者的服务地址，确定所述所有消息订阅者的服务地址中哈希值最小的服务地址；

向所述哈希值最小的服务地址发送所述反馈消息。

4.根据权利要求1～3任一项所述的方法，其特征在于，所述接收用户端上传的第一任务，包括：

接收用户端上传的任务请求消息，所述任务请求消息携带令牌和所述第一任务；

所述接收用户端上传的第一任务之后，所述方法还包括：

校验所述令牌是否合法，判断所述令牌是否过期；

若所述令牌合法且未过期，执行所述创建并持久化所述第一任务的任务数据的步骤。

5.根据权利要求4所述的方法，其特征在于，所述将包含所述任务数据的任务数据消息投递到第一消息队列之后，所述方法还包括：

返回所述第一任务的任务标识到所述用户端；

接收所述用户端发送的针对所述第一任务的查询消息，所述查询消息携带所述任务标识和所述令牌，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

校验所述令牌是否合法，判断所述令牌是否过期；

若所述令牌合法且未过期，响应所述查询消息返回查询结果到所述用户端。

6.根据权利要求1～5任一项所述的方法，其特征在于，所述更新持久化的所述任务数据之后，所述方法还包括：

根据所述任务数据确定所述第一任务的任务状态；

若所述第一任务的任务状态为“已失败”，采用异步方式删除用户端上传至文件存储系统的初始资源文件；或者，若所述第一任务的任务状态为“结果已获取”，采用异步方式删除用户端上传至文件存储系统的初始资源文件和/或处理后的资源文件，所述处理后的资源文件是所述初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务；又或者，

若所述第一任务的任务状态为“已成功”，并且所述处理后的资源文件在所述文件存储系统的存放时长达到设定阈值，删除所述初始资源文件和/或所述处理后的资源文件。

7.一种任务处理方法，其特征在于，所述方法应用于用户端，所述方法包括：

获取接口密钥，根据所述接口密钥获取带有有效期的令牌；

将所述令牌放入任务请求消息，向服务端发送所述任务请求消息，所述任务请求消息携带第一任务，所述任务请求消息用于请求所述服务端处理所述第一任务，所述服务端用于创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列；以及用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第一消息队列为生产者消费者模式的队列，所述第二消息队列为发布订阅模式的队列。

8.根据权利要求7所述的方法，其特征在于，所述向服务端发送所述任务请求消息之后，所述方法还包括：

上传与所述第一任务对应的初始资源文件到文件存储系统。

9.根据权利要求8所述的方法，其特征在于，所述向服务端发送所述任务请求消息之后，所述方法还包括：

获取所述服务端发送的所述第一任务的任务标识；

将所述任务标识和所述令牌放入查询消息，向所述服务端发送所述查询消息，所述查询消息包括任务执行进度查询消息和任务状态查询消息中的至少一种；

在所述令牌合法且未过期的情况下，接收所述服务端针对所述查询消息返回的查询结果。

10.根据所述权利要求9所述的方法，其特征在于，所述接收所述服务端针对所述查询消息返回的查询结果之后，所述方法还包括：

若所述查询结果包括任务状态为“已成功”，将所述任务标识和所述令牌放入文件下载请求消息，向所述服务端发送所述文件下载请求消息；

在所述令牌合法且未过期的情况下，从文件存储系统下载处理后的资源文件，所述处理后的资源文件是用户端上传至所述文件存储系统的初始资源文件经过所述第一任务处理后得到的，所述第一任务包括针对所述初始资源文件的处理任务。

11.一种任务处理装置，其特征在于，所述装置应用于服务端，所述装置包括：

接收单元，用于接收用户端上传的第一任务；

创建单元，用于创建并持久化所述第一任务的任务数据；

任务投递单元，用于将包含所述任务数据的任务数据消息投递到第一消息队列，所述第一消息队列为生产者消费者模式的队列；

更新单元，用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第二消息队列为发布订阅模式的队列。

12.一种任务处理装置，其特征在于，所述装置应用于用户端，所述装置包括：

获取单元，用于获取接口密钥，根据所述接口密钥获取带有有效期的令牌；

任务请求单元，用于将所述令牌放入任务请求消息，向服务端发送所述任务请求消息，所述任务请求消息携带第一任务，所述任务请求消息用于请求所述服务端处理所述第一任务，所述服务端用于创建并持久化所述第一任务的任务数据，将包含所述任务数据的任务数据消息投递到第一消息队列；以及用于在监听到所述第一任务的执行反馈消息进入第二消息队列的情况下，更新持久化的所述任务数据，所述第一消息队列为生产者消费者模式的队列，所述第二消息队列为发布订阅模式的队列。

13.一种服务器，其特征在于，包括处理器和存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求1～6任一项所述的方法。

14.一种电子设备，其特征在于，包括处理器和存储器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求7～10任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行如权利要求1～10任一项所述的方法。

Images