CN111061550A - 任务处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种任务处理方法、装置、设备及存储介质，属于计算机技术领域。本申请融合了消息队列和定时任务以驱动任务的处理流程，通过检测消息队列的状态，来自动感知消息队列当前是否故障，若消息队列处于故障状态，则自动切换为定时任务模式，通过按照一定的时间周期继续处理任务，如此，可以实现消息队列优先而定时任务兜底的功能，即使消息队列发生故障，系统的任务处理流程也不会中断，而是会基于定时任务模式继续驱动任务进行处理，因此，可保障系统在消息队列故障的情况下仍可以稳定地执行任务，因此提高了系统的鲁棒性，在消息队列故障期间能够极大地提高任务的处理效率。

Description

任务处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种任务处理方法、装置、设备及存储介质。

背景技术

随着计算机技术和电子商务的发展，可由计算机执行的任务越来越多，比如说，当用户下了一笔订单时，订单的生成、订单的支付、订单的物流状态、订单的完成等等，对于计算机而言都是要执行的任务。由此可见，如何让计算机能够稳定、高效地处理任务，对于计算机技术而言是至关重要的。

相关技术中，通常仅依赖消息队列处理任务。具体地，计算机会创建消息队列，将待处理的每个任务作为消息队列中的一个消息，存入至消息队列中。之后，计算机会按照先入先出的规则，从消息队列中依次取出各个任务，对取出的任务进行处理。在此期间，如果系统产生了新的任务，则计算机会将新的任务继续存入至消息队列中。

采用上述方法时，一旦消息队列发生故障，就会导致任务处理流程随之中断，在技术人员人工介入以修复消息队列之前，系统产生的所有任务均无法得到处理。由此可见，上述方法的鲁棒性很差，并且会在消息队列故障期间极大地影响任务的处理效率。

发明内容

本申请实施例提供了一种任务处理方法、装置、设备及存储介质，能够解决相关技术中消息队列故障期间任务无法得到处理的问题。所述技术方案如下：

一方面，提供了一种任务处理方法，所述方法包括：

在消息队列模式下，对消息队列中的任务进行处理；

检测所述消息队列的状态；

若所述消息队列处于故障状态，将任务处理模式从所述消息队列模式切换为定时任务模式；

在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理。

可选地，所述检测所述消息队列的状态，包括：

检测历史时间段内向消息队列发送的失败应答的数量；

若所述失败应答的数量达到阈值，确定所述消息队列处于故障状态；或者，若所述失败应答的数量未达到阈值，确定所述消息队列处于正常状态。

可选地，所述检测所述消息队列的状态，包括：

检测历史时间段内向消息队列发送的失败应答的数量以及成功应答的数量；

根据所述失败应答的数量以及所述成功应答的数量，获取所述消息队列的失败率，所述失败率与所述失败应答的数量正相关，所述失败率与所述成功应答的数量负相关；

若所述消息队列的失败率达到阈值，确定所述消息队列处于故障状态；或者，若所述消息队列的失败率未达到阈值，确定所述消息队列处于正常状态。

可选地，所述将任务处理模式从所述消息队列模式切换为定时任务模式之后，所述方法还包括：

若所述消息队列从所述故障状态中恢复，将所述任务处理模式从所述定时任务模式切换为所述消息队列模式；

在消息队列模式下，对消息队列中的任务进行处理。

可选地，所述每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理之前，所述方法还包括：

接收配置指令，所述配置指令用于指示配置所述定时任务模式的时间周期；

根据所述配置指令，为所述定时任务模式设置所述时间周期。

可选地，所述每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理之前，所述方法还包括：

检测当前待执行的任务数量；

根据所述任务数量，为所述定时任务模式设置所述时间周期，所述时间周期与所述任务数量负相关。

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

从终端接收订单；

根据所述订单，生成至少一个任务，每个任务用于指示执行所述订单关联的操作；

在所述消息队列模式下，将所述至少一个任务添加至所述消息队列中；或者，在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对所述至少一个任务中的一个任务进行处理；

向所述终端发送任务的处理结果。

另一方面，提供了一种任务处理装置，所述装置包括：

第一处理模块，用于在消息队列模式下，对消息队列中的任务进行处理；

检测模块，用于检测所述消息队列的状态；

切换模块，用于若所述消息队列处于故障状态，将任务处理模式从所述消息队列模式切换为定时任务模式；

第二处理模块，用于在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理。

可选地，所述检测模块，用于检测历史时间段内向消息队列发送的失败应答的数量；若所述失败应答的数量达到阈值，确定所述消息队列处于故障状态；或者，若所述失败应答的数量未达到阈值，确定所述消息队列处于正常状态。

可选地，所述检测模块，用于检测历史时间段内向消息队列发送的失败应答的数量以及成功应答的数量；根据所述失败应答的数量以及所述成功应答的数量，获取所述消息队列的失败率，所述失败率与所述失败应答的数量正相关，所述失败率与所述成功应答的数量负相关；若所述消息队列的失败率达到阈值，确定所述消息队列处于故障状态；或者，若所述消息队列的失败率未达到阈值，确定所述消息队列处于正常状态。

可选地，所述切换模块，用于若所述消息队列从所述故障状态中恢复，将所述任务处理模式从所述定时任务模式切换为所述消息队列模式；在消息队列模式下，对消息队列中的任务进行处理。

可选地，所述装置还包括：

接收模块，用于接收配置指令，所述配置指令用于指示配置所述定时任务模式的时间周期；

设置模块，用于根据所述配置指令，为所述定时任务模式设置所述时间周期。

可选地，所述检测模块，还用于检测当前待执行的任务数量；

所述装置还包括：设置模块，用于根据所述任务数量，为所述定时任务模式设置所述时间周期，所述时间周期与所述任务数量负相关。

可选地，所述装置还包括：接收模块，用于从终端接收订单；

生成模块，用于根据所述订单，生成至少一个任务，每个任务用于指示执行所述订单关联的操作；

添加模块，用于在所述消息队列模式下，将所述至少一个任务添加至所述消息队列中；

第二处理模块，用于在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对所述至少一个任务中的一个任务进行处理；

发送模块，用于向所述终端发送任务的处理结果。

另一方面，提供了一种电子设备，所述电子设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条指令，所述至少一条指令由所述一个或多个处理器加载并执行以实现上述任务处理方法所执行的操作。

另一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现上述任务处理方法所执行的操作。

本申请实施例提供的技术方案带来的有益效果至少包括：

本实施例提供了融合消息队列和定时任务以驱动任务的处理流程的方法，通过检测消息队列的状态，来自动感知消息队列当前是否故障，若消息队列处于故障状态，则自动切换为定时任务模式，通过按照一定的时间周期继续处理任务，如此，可以实现消息队列优先而定时任务兜底的功能，即使消息队列发生故障，系统的任务处理流程也不会中断，而是会基于定时任务模式继续驱动任务进行处理，因此，可以保障系统在消息队列故障的情况下仍可以稳定地执行任务，因此提高了系统的鲁棒性，在消息队列故障期间能够极大地提高任务的处理效率。

附图说明

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

图1是本申请实施例提供的一种任务处理方法的实施环境的示意图；

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

图3是本申请实施例提供的一种故障切换引擎的结构示意图；

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

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

图6是本申请实施例提供的一种终端的结构示意图；

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

具体实施方式

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

本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本申请中的字符“/”，一般表示前后关联对象是一种“或”的关系。

本申请中术语“多个”的含义是指两个或两个以上，例如，多个数据包是指两个或两个以上的数据包。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”、“第n”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。

图1是本申请实施例提供的一种任务处理方法的实施环境的示意图。该实施环境包括：终端110和业务系统120。终端110通过无线网络或有线网络与业务系统120相连。

终端110可以是智能手机、游戏主机、台式计算机、平板电脑、电子书阅读器、MP3(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)播放器或MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器和膝上型便携计算机中的至少一种。终端110安装和运行有应用程序。该应用程序可以是电商应用、社交应用等。示例性的，终端110是用户使用的终端，终端110中运行的应用程序内登录有用户账号，用户可以基于用户账号进行资源转移，比如进行下单，从而将用户账号中的虚拟货币与商户的资源进行交换。

业务系统120包括一台服务器、多台服务器、云计算平台和虚拟化中心中的至少一种。业务系统120用于为应用程序提供后台服务。

可选地，业务系统120包括：服务器1201和数据库1202。服务器1201用于提供后台服务。服务器1201可以是一台或多台。当服务器1201是多台时，存在至少两台服务器1201用于提供不同的服务，和/或，存在至少两台服务器1201用于提供相同的服务，比如以负载均衡方式提供同一种服务，本申请实施例对此不加以限定。数据库1202用于存储数据，服务器1201可以访问数据库1202，读取数据库1202存储的数据。或者服务器1201可以将数据写入至数据库1202。

本领域技术人员可以知晓，上述终端、服务器和数据库的数量可以更多或更少。比如上述终端、服务器和数据库可以仅为一个，或者上述终端、服务器和数据库为几十个或几百个，或者更多数量，此时虽然图1未示出，上述实施环境还包括其他终端、其他服务器以及其他数据库。本申请实施例对终端、服务器和数据库的数量和设备类型不加以限定。

以上示例性描述了本申请实施例的一种硬件环境，以下基于该硬件环境，对本申请实施例的方法流程进行描述。

消息队列(Message Queue,MQ)是一种不同程序之间的通信机制。消息队列基于生产者—消费者的模型设计，生产者生产消息，将消息写入至消息队列中，消费者可以读取队列中的消息，对消息进行处理。消息队列在性能上具有很大的优势，然而在相关技术中，基于消息队列的系统架构对于消息队列的稳定性要求很高。这是由于，以往的技术方案中，通常仅依赖于消息队列来处理业务，一旦消息队列故障，系统就无法继续处理任务，造成系统的可用性会极大的下降，也就影响了业务的处理效率。

有鉴于此，本实施例提供了一种支持消息队列故障探测和故障切换的方法，能够自动感知到消息队列的故障，一旦消息队列发生故障，则将驱动任务执行的模式自动切换为定时任务模式，使得业务仍能够基于定时任务模式得到正常处理，从而避免业务随着消息队列的故障而发生中断。如此，打破了传统技术中人工介入修复消息队列后，任务才能被继续处理的限制，有助于系统高效、快速地从故障状态下恢复。

图2是本申请实施例提供的一种任务处理方法的流程图，以图2为例，对处理任务的流程描述如下：

201、电子设备在消息队列模式下，对消息队列中的任务进行处理。

本实施例中，融合了两种驱动任务的模式，分别是消息队列模式以及定时任务模式。基于这种架构，可以实现消息队列优先、定时任务兜底的功能：若消息队列处于正常状态，未发生故障，可以通过消息队列来处理任务；若消息队列处于故障状态，则启动定时任务模式，按照设置的时间周期来处理任务。

其中，消息队列模式是一种驱动任务执行的模式，具体是指每当一个待处理的任务产生时，将该任务视为消息队列的消息，添加至消息队列中，当满足预设条件时，从消息队列获取该任务，对该任务进行处理。

例如，参见图3，可以构建故障切换引擎，该故障切换引擎为一种软件，包括多个功能模块，例如包括故障探测模块、故障切换模块、消息上报模块、消息发送模块等。故障切换引擎具有通用性和可扩展性。参见图3，故障切换引擎可以将消息队列模式作为默认的任务驱动模式，若消息队列未故障，则开启消息队列模式，而关闭定时任务模式。在消息队列模式下，当前流程节点会自动向下一个流程节点发送MQ消息，下一个流程节点会接收MQ消息，对MQ消息进行处理。而每个MQ消息代表着一个任务，比如是订单的存储操作，那么下一个流程节点通过处理MQ消息，即实现了任务处理的功能。

202、电子设备检测消息队列的状态。

消息队列的状态可以包括故障状态以及正常状态。通过检测消息队列的状态，能够在消息队列产生故障时，自动感知到消息队列的故障，以便及时进行任务模式的切换。

对消息队列进行故障探测的实现方式可以有多种。在一些可能的实现方式中，可以基于监听机制，通过监听发往消息队列的应答消息，来探测消息队列是否出现故障。

具体而言，消息队列通常基于消息应答(Message acknowledgment)机制来保证消息的传输可靠性，每当消费者对消息处理完成，可以生成应答消息(也称确认消息、响应消息或反馈消息，英文：Acknowledge，简称：ACK)，将应答消息发送给消息队列，从而通过消息队列进行响应。

其中，应答消息可以包括成功应答以及失败应答。成功应答用于通知消息已经被接收并处理完成，即消息成功得到消费。消息队列接收到成功应答后，可以删除该消息。失败应答用于通知消息未被接收或未被处理完成，消息队列接收到失败应答后，可以确定消息未被成功消费，消息需要通过其他消费者或其他队列重新进行处理。

结合消息应答机制，以下通过实现方式一至实现方式二，对进行故障探测的方式进行举例说明。

实现方式一、利用失败率进行判断。

实现方式一可以包括以下步骤一至步骤五。

步骤一、检测历史时间段内向消息队列发送的失败应答的数量以及成功应答的数量。

其中，该历史时间段的时长可以根据实验、经验或需求配置，例如历史时间段可以是最近一分钟。例如，参见图3，当前流程节点发送MQ消息后，可以将发送消息的结果，通过应答消息上报至故障切换引擎，故障切换引擎可以记录应答消息，以便统计最近一分钟内发送消息的总数量和发送消息失败的数量。

步骤二、根据失败应答的数量以及成功应答的数量，获取消息队列的失败率。

其中，失败率与失败应答的数量正相关，失败率与成功应答的数量负相关。例如，失败率可以是失败应答的数量与应答消息的总数量之间的比值，该应答消息的总数量可以是成功应答的数量以及失败应答的数量的和值。

步骤三、对失败率与阈值进行比较，若失败率达到阈值，执行步骤四，若失败率未达到阈值，执行步骤五。

其中，失败率的阈值可以通过配置中心维护。例如，技术人员可以执行配置操作，输入失败率的阈值，配置中心可以检测配置操作，获取失败率的阈值。

步骤四、确定消息队列处于故障状态。

步骤五、确定消息队列处于正常状态。

实现方式二、利用失败数量进行判断。

实现方式二可以包括以下步骤一至步骤四。

步骤一、检测历史时间段内向消息队列发送的失败应答的数量。

步骤二、对失败应答的数量与阈值进行比较，若失败应答的数量达到阈值，执行步骤三，若失败应答的数量未达到阈值，执行步骤四。

其中，失败应答的数量的阈值可以通过配置中心维护。例如，技术人员可以执行配置操作，输入失败应答的数量的阈值，配置中心可以检测配置操作，获取失败应答的数量的阈值。

步骤三、确定消息队列处于故障状态。

步骤四、确定消息队列处于正常状态。

应理解，上述实现方式一与实现方式二可以采用任意方式结合。如果将不同实现方式结合起来，不同实现方式之间的逻辑关系可以是且的关系，也可以是或的关系。例如，电子设备可以检测历史时间段内消息队列的失败率，且检测历史时间段内向消息队列发送的失败应答的数量，若失败率达到阈值且失败应答的数量达到阈值，确定消息队列处于故障状态。

203、若消息队列处于故障状态，电子设备将任务处理模式从消息队列模式切换为定时任务模式。

参见图3，如果消息队列发生故障，可以开启定时任务模式，以便在定时任务模式下处理任务。

其中，定时任务模式是一种驱动任务执行的模式，定时任务模式与上文描述的消息队列模式不同。定时任务模式具体是指按照指定的频率，每隔一段时间执行一个任务的模式。

在一些实施例中，若检测到消息队列处于故障状态，可以向目标终端发送通知消息，该目标终端可以是登录有消息队列的负责人的用户账号的终端，该通知消息用于通知消息队列处于故障状态，目标终端接收到通知消息时，可以提示消息队列处于故障状态，比如在界面中显示提示信息、播放提示音频等，以便消息队列的负责人可以第一时间得知消息队列出现故障，排查消息队列的问题，从而通过人工介入来修复消息队列的故障。此外，该目标终端也可以是登录有定时任务的负责人的用户账号的终端，定时任务的负责人可以通过手动调高调度频率，来确保业务及时处理。

204、在定时任务模式下，每隔定时任务模式所设置的时间周期，电子设备对当前时间周期接收到的任务进行处理。

具体地，可以为定时任务模式设置对应的时间周期，若从消息队列模式切换为定时任务模式，如果系统产生了新的任务，可以不再将新的任务添加至消息队列，而是按照该时间周期来定时处理任务。例如，可以每隔时间周期，扫描一次数据库中的表，对扫描得到的任务进行处理。

其中，定时任务模式对应的时间周期可以通过多种方式设置，例如通过配置中心设置。定时任务模式对应的时间周期可以预先设定，也可以依据当前的任务量动态调整。以下，通过实现方式一至实现方式二，对配置定时任务模式对应的时间周期的方式举例说明。

实现方式一、通过操作来配置。

实现方式一可以包括以下步骤1.1至步骤1.2：

步骤1.1、接收配置指令。

具体地，开发人员可以依据经验，设定定时任务模式的时间周期，执行配置操作，触发配置指令。其中，配置指令用于指示配置定时任务模式的时间周期，配置指令可以包括定时任务模式的时间周期。

步骤1.2、根据配置指令，为定时任务模式设置时间周期。

可以解析配置指令，得到配置指令携带的定时任务模式的时间周期，将该时间周期设置为定时任务模式的时间周期。

实现方式二、根据任务量来配置。

实现方式二可以包括以下步骤2.1至步骤2.2：

步骤2.1、检测当前待执行的任务数量。

步骤2.2、根据任务数量，为定时任务模式设置时间周期。

其中，目标时长与任务数量负相关，也即是，当前待执行的任务数量越多，则定时任务模式下执行任务的频率越高，以保证任务得到及时处理，加速任务的处理过程。

以上描述了消息队列故障后自动切换的流程。随着时间的推移，消息队列可以从故障状态中恢复，比如由于人工的介入，修复了消息队列的故障，使得消息队列已经可以正常处理任务。本实施例中，可以当消息队列恢复时，自动切换回消息队列模式。以下，通过步骤205，对消息队列恢复时自动切换的流程进行描述。

205、若消息队列从故障状态中恢复，电子设备将任务处理模式从定时任务模式切换为消息队列模式。

例如，若技术人员对消息队列的故障进行了修复，可以执行消息队列启动操作，电子设备检测到消息队列启动操作，可以将任务处理模式重新切换至消息队列模式。

以下，对步骤205至少包括的效果进行描述：

考虑到定时任务模式下，会定时扫描数据库表，增加数据库的压力，同时，若数据库的队列出现积压，也会影响业务的执行效率。因此，在消息队列恢复后，故障切换引擎通过将驱动任务的模式切换为消息队列模式，可以提高任务处理效率，规避对数据库的频繁扫描，从而减轻数据库的压力。

206、电子设备在消息队列模式下，对消息队列中的任务进行处理。

当将任务处理模式切换回消息队列模式时，可以将新产生的任务重新添加至消息队列中，将任务从消息队列中出列，对得到的任务进行处理。此外，对于消息队列故障前，已经通过消息的形式预先在消息队列中缓存的任务而言，可以删除该任务，也可以检测该任务是否处于完成状态，若任务处于完成状态，可以删除该任务，若任务处于未完成状态，则执行该任务。

本实施例提供了融合消息队列和定时任务以驱动任务的处理流程的方法，通过检测消息队列的状态，来自动感知消息队列当前是否故障，若消息队列处于故障状态，则自动切换为定时任务模式，通过按照一定的时间周期继续处理任务，如此，可以实现消息队列优先而定时任务兜底的功能，即使消息队列发生故障，系统的任务处理流程也不会中断，而是会基于定时任务模式继续驱动任务进行处理，因此，可以保障系统在消息队列故障的情况下仍可以稳定地执行任务，因此提高了系统的鲁棒性，在消息队列故障期间能够极大地提高任务的处理效率。

上述技术方案可以应用在多种场景中。例如，可以应用在电商应用中用户下单的场景中。以下结合这一应用场景，对本实施例提供的技术方案进行举例说明。

参见图4，任务处理的交互流程可以包括以下步骤：

401、终端检测到用户的支付操作，生成订单。

402、终端向服务器发送订单。

403、服务器从终端接收订单，根据订单，生成至少一个任务，每个任务用于指示执行订单关联的操作。

一个订单从创建到处理完成会经过多个业务流程节点，任何一个节点出现问题都可能影响到订单的整体处理效率。例如，用户下单后，需要对订单持久化存储至数据库、向用户返回已下单成功、从用户的账户扣款、向商户的账户付款等等，这些操作都可以视为一种任务。

其中，服务器生成订单对应的任务时，可以检测消息队列是否为正常状态，若消息队列处于正常状态，则服务器会在消息队列模式下，将至少一个任务添加至消息队列中。

404、服务器在消息队列模式下，对消息队列中的任务进行处理。

405、服务器检测消息队列的状态。

406、若消息队列处于故障状态，服务器在定时任务模式下，每隔定时任务模式所设置的时间周期，对订单关联的至少一个任务中的一个任务进行处理。

407、服务器向终端发送任务的处理结果。

408、终端根据任务的处理结果，在界面中显示订单的状态。

图5是本申请实施例提供的一种任务处理装置的结构示意图。参见图5，该装置包括：

第一处理模块501，用于在消息队列模式下，对消息队列中的任务进行处理；

检测模块502，用于检测消息队列的状态；

切换模块503，用于若消息队列处于故障状态，将任务处理模式从消息队列模式切换为定时任务模式；

第二处理模块504，用于在定时任务模式下，每隔定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理。

本实施例提供了融合消息队列和定时任务以驱动任务的处理流程的装置，通过检测消息队列的状态，来自动感知消息队列当前是否故障，若消息队列处于故障状态，则自动切换为定时任务模式，通过按照一定的时间周期继续处理任务，如此，可以实现消息队列优先而定时任务兜底的功能，即使消息队列发生故障，系统的任务处理流程也不会中断，而是会基于定时任务模式继续驱动任务进行处理，因此，可以保障系统在消息队列故障的情况下仍可以稳定地执行任务，因此提高了系统的鲁棒性，在消息队列故障期间能够极大地提高任务的处理效率。

可选地，检测模块502，用于检测历史时间段内向消息队列发送的失败应答的数量；若失败应答的数量达到阈值，确定消息队列处于故障状态；或者，若失败应答的数量未达到阈值，确定消息队列处于正常状态。

可选地，检测模块502，用于检测历史时间段内向消息队列发送的失败应答的数量以及成功应答的数量；根据失败应答的数量以及成功应答的数量，获取消息队列的失败率，失败率与失败应答的数量正相关，失败率与成功应答的数量负相关；若消息队列的失败率达到阈值，确定消息队列处于故障状态；或者，若消息队列的失败率未达到阈值，确定消息队列处于正常状态。

可选地，切换模块503，用于若消息队列从故障状态中恢复，将任务处理模式从定时任务模式切换为消息队列模式；在消息队列模式下，对消息队列中的任务进行处理。

可选地，装置还包括：

接收模块，用于接收配置指令，配置指令用于指示配置定时任务模式的时间周期；

设置模块，用于根据配置指令，为定时任务模式设置时间周期。

可选地，检测模块502，还用于检测当前待执行的任务数量；

装置还包括：设置模块，用于根据任务数量，为定时任务模式设置时间周期，目标时长与任务数量负相关。

可选地，装置还包括：接收模块，用于从终端接收订单；

生成模块，用于根据订单，生成至少一个任务，每个任务用于指示执行订单关联的操作；

添加模块，用于在消息队列模式下，将至少一个任务添加至消息队列中；

第二处理模块504，用于在定时任务模式下，每隔定时任务模式所设置的时间周期，对至少一个任务中的一个任务进行处理；

发送模块，用于向终端发送任务的处理结果。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

需要说明的是：上述实施例提供的任务处理装置在处理任务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将任务处理装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的任务处理装置与任务处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述方法实施例中的电子设备可以实现为终端，例如，图6示出了本申请一个示例性实施例提供的终端600的结构框图。该终端600可以是：智能手机、平板电脑、MP3(MovingPicture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)播放器、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端600还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端600包括有：一个或多个处理器601和一个或多个存储器602。

处理器601可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器601可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器601也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器601可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器601还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器602可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器602还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器602中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器601所执行以实现本申请中方法实施例提供的任务处理方法。

在一些实施例中，终端600还可选包括有：外围设备接口603和至少一个外围设备。处理器601、存储器602和外围设备接口603之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口603相连。具体地，外围设备包括：射频电路604、触摸显示屏605、摄像头组件606、音频电路607、定位组件608和电源609中的至少一种。

外围设备接口603可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器601和存储器602。在一些实施例中，处理器601、存储器602和外围设备接口603被集成在同一芯片或电路板上；在一些其他实施例中，处理器601、存储器602和外围设备接口603中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路604用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路604通过电磁信号与通信网络以及其他通信设备进行通信。射频电路604将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路604包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路604可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路604还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏605用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏605是触摸显示屏时，显示屏605还具有采集在显示屏605的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器601进行处理。此时，显示屏605还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏605可以为一个，设置终端600的前面板；在另一些实施例中，显示屏605可以为至少两个，分别设置在终端600的不同表面或呈折叠设计；在再一些实施例中，显示屏605可以是柔性显示屏，设置在终端600的弯曲表面上或折叠面上。甚至，显示屏605还可以设置成非矩形的不规则图形，也即异形屏。显示屏605可以采用LCD(LiquidCrystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件606用于采集图像或视频。可选地，摄像头组件606包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件606还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路607可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器601进行处理，或者输入至射频电路604以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端600的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器601或射频电路604的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路607还可以包括耳机插孔。

定位组件608用于定位终端600的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件608可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统或俄罗斯的伽利略系统的定位组件。

电源609用于为终端600中的各个组件进行供电。电源609可以是交流电、直流电、一次性电池或可充电电池。当电源609包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端600还包括有一个或多个传感器610。该一个或多个传感器610包括但不限于：加速度传感器611、陀螺仪传感器612、压力传感器613、指纹传感器614、光学传感器615以及接近传感器616。

加速度传感器611可以检测以终端600建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器611可以用于检测重力加速度在三个坐标轴上的分量。处理器601可以根据加速度传感器611采集的重力加速度信号，控制触摸显示屏605以横向视图或纵向视图进行用户界面的显示。加速度传感器611还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器612可以检测终端600的机体方向及转动角度，陀螺仪传感器612可以与加速度传感器611协同采集用户对终端600的3D动作。处理器601根据陀螺仪传感器612采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器613可以设置在终端600的侧边框和/或触摸显示屏605的下层。当压力传感器613设置在终端600的侧边框时，可以检测用户对终端600的握持信号，由处理器601根据压力传感器613采集的握持信号进行左右手识别或快捷操作。当压力传感器613设置在触摸显示屏605的下层时，由处理器601根据用户对触摸显示屏605的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器614用于采集用户的指纹，由处理器601根据指纹传感器614采集到的指纹识别用户的身份，或者，由指纹传感器614根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器601授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器614可以被设置终端600的正面、背面或侧面。当终端600上设置有物理按键或厂商Logo时，指纹传感器614可以与物理按键或厂商Logo集成在一起。

光学传感器615用于采集环境光强度。在一个实施例中，处理器601可以根据光学传感器615采集的环境光强度，控制触摸显示屏605的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏605的显示亮度；当环境光强度较低时，调低触摸显示屏605的显示亮度。在另一个实施例中，处理器601还可以根据光学传感器615采集的环境光强度，动态调整摄像头组件606的拍摄参数。

接近传感器616，也称距离传感器，通常设置在终端600的前面板。接近传感器616用于采集用户与终端600的正面之间的距离。在一个实施例中，当接近传感器616检测到用户与终端600的正面之间的距离逐渐变小时，由处理器601控制触摸显示屏605从亮屏状态切换为息屏状态；当接近传感器616检测到用户与终端600的正面之间的距离逐渐变大时，由处理器601控制触摸显示屏605从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图6中示出的结构并不构成对终端600的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

上述方法实施例中的电子设备可以实现为服务器，例如，图7是本申请实施例提供的一种服务器的结构示意图，该服务器700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(Central Processing Units，CPU)701和一个或一个以上的存储器702，其中，存储器702中存储有至少一条指令，至少一条指令由处理器701加载并执行以实现上述各个方法实施例提供的任务处理方法。当然，该服务器还可以具有有线或无线网络接口以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由处理器执行以完成上述实施例中的任务处理方法。例如，计算机可读存储介质可以是只读存储器(Read-Only Memory，简称：ROM)、随机存取存储器(Random AccessMemory，简称：RAM)、只读光盘(Compact Disc Read-Only Memory，简称：CD-ROM)、磁带、软盘和光数据存储设备等。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

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

在消息队列模式下，对消息队列中的任务进行处理；

检测所述消息队列的状态；

若所述消息队列处于故障状态，将任务处理模式从所述消息队列模式切换为定时任务模式；

在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理。

2.根据权利要求1所述的方法，其特征在于，所述检测所述消息队列的状态，包括：

检测历史时间段内向消息队列发送的失败应答的数量；

若所述失败应答的数量达到阈值，确定所述消息队列处于故障状态；或者，若所述失败应答的数量未达到阈值，确定所述消息队列处于正常状态。

3.根据权利要求1所述的方法，其特征在于，所述检测所述消息队列的状态，包括：

检测历史时间段内向消息队列发送的失败应答的数量以及成功应答的数量；

根据所述失败应答的数量以及所述成功应答的数量，获取所述消息队列的失败率，所述失败率与所述失败应答的数量正相关，所述失败率与所述成功应答的数量负相关；

若所述消息队列的失败率达到阈值，确定所述消息队列处于故障状态；或者，若所述消息队列的失败率未达到阈值，确定所述消息队列处于正常状态。

4.根据权利要求1所述的方法，其特征在于，所述将任务处理模式从所述消息队列模式切换为定时任务模式之后，所述方法还包括：

若所述消息队列从所述故障状态中恢复，将所述任务处理模式从所述定时任务模式切换为所述消息队列模式；

在消息队列模式下，对消息队列中的任务进行处理。

5.根据权利要求1所述的方法，其特征在于，所述每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理之前，所述方法还包括：

接收配置指令，所述配置指令用于指示配置所述定时任务模式的时间周期；

根据所述配置指令，为所述定时任务模式设置所述时间周期。

6.根据权利要求1所述的方法，其特征在于，所述每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理之前，所述方法还包括：

检测当前待执行的任务数量；

根据所述任务数量，为所述定时任务模式设置所述时间周期，所述时间周期与所述任务数量负相关。

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

从终端接收订单；

根据所述订单，生成至少一个任务，每个任务用于指示执行所述订单关联的操作；

在所述消息队列模式下，将所述至少一个任务添加至所述消息队列中；或者，在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对所述至少一个任务中的一个任务进行处理；

向所述终端发送任务的处理结果。

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

第一处理模块，用于在消息队列模式下，对消息队列中的任务进行处理；

检测模块，用于检测所述消息队列的状态；

切换模块，用于若所述消息队列处于故障状态，将任务处理模式从所述消息队列模式切换为定时任务模式；

第二处理模块，用于在所述定时任务模式下，每隔所述定时任务模式所设置的时间周期，对当前时间周期接收到的任务进行处理。

9.一种电子设备，其特征在于，所述电子设备包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条指令，所述至少一条指令由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求7任一项所述的任务处理方法所执行的操作。

10.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现如权利要求1至权利要求7任一项所述的任务处理方法所执行的操作。

Images