CN106888135A

CN106888135A - 一种任务状态的查询方法和装置

Info

Publication number: CN106888135A
Application number: CN201510938626.1A
Authority: CN
Inventors: 杨剑
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-12-15
Filing date: 2015-12-15
Publication date: 2017-06-23
Anticipated expiration: 2035-12-15
Also published as: WO2017101701A1; CN106888135B

Abstract

本申请实施例提供了一种任务状态的查询方法和装置，该方法包括：向服务器发送针对指定任务的任务状态的查询请求；当接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；当所述任务状态为任务运行中时，根据所述响应消息设置下一次的查询时间；当经过下一次的查询时间时，返回执行所述向服务器发送针对指定任务的任务状态的查询请求的步骤。本申请实施例实现动态轮询，避免了连续不断的请求冲垮服务器，同时，减少了获取任务状态的时间，减少延迟，提高实时性。

Description

一种任务状态的查询方法和装置

技术领域

本申请涉及通信技术领域，特别是涉及一种任务状态的查询方法和一种任务状态的查询装置。

背景技术

在许多普通的网站，如社交网站、微博等，用户在登录之后，通常要实时向网站的服务器查询用户的账号是否有新的消息、是否有新的通知、是否有新的留言等等，如果有，则拉取并展示。

现在通常是间隔一段固定的时间去服务器查询用户的账号是否有改变，从而进行增量式的更新。

但是，间隔多长时间去查询成了问题，因为性能和即时性造成了严重的反比关系。

若间隔的时间太短，连续不断的请求容易冲垮服务器。

若间隔的时间太长，服务器上的新数据就需要越多的时间才能到达客户端，产生延迟、实时性差。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种任务状态的查询方法和相应的一种任务状态的查询装置。

为了解决上述问题，本申请实施例公开了一种任务状态的查询方法，包括：

向服务器发送针对指定任务的任务状态的查询请求；

当接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；

当所述任务状态为任务运行中时，根据所述响应消息设置下一次的查询时间；

判断是否经过下一次的查询时间，若是，则返回执行所述向服务器发送针对指定任务的任务状态的查询请求的步骤。

优选地，所述向服务器发送查询指定任务的任务状态的请求的步骤包括：

查找在预设的消息队列中的任务标识；

向服务器发送查询所述任务标识对应的任务状态的请求。

优选地，所述根据所述响应消息设置下一次的查询时间的步骤包括：

计算所述响应消息中运行日志信息的日志长度；

按照所述日志长度设置下一次的查询时间。

优选地，所述按照所述日志长度设置下一次的查询时间的步骤包括：

当所述日志长度大于或等于第一长度阈值时，设置下一次的查询时间为第一时间；

当所述日志长度大于或等于第二长度阈值、且小于第一长度阈值时，设置下一次的查询时间为第二时间；

当所述日志长度小于第二长度阈值时，设置下一次的查询时间为第三时间；

其中，所述第一长度阈值大于所述第二长度阈值；

所述第一时间小于所述第二时间，所述第二时间小于所述第三时间。

从所述响应消息中提取服务器的运行负载信息；

按照所述运行负载信息设置下一次的查询时间。

优选地，所述按照所述运行负载信息设置下一次的查询时间的步骤包括：

当所述运行负载信息为快速运行时，设置下一次的查询时间为第四时间；

当所述运行负载信息为正常运行时，设置下一次的查询时间为第五时间；

当所述运行负载信息为慢速运行时，设置下一次的查询时间为第六时间；

其中，所述第四时间小于所述第五时间，所述第五时间小于所述第六时间。

优选地，还包括：

针对任务运行中的任务状态生成提示信息；

展示所述响应消息中的运行日志信息。

优选地，还包括：

当所述任务状态为任务运行成功时，针对任务运行成功的任务状态生成提示信息；

向服务器请求所述任务的运行结果；

当请求到运行结果时，展示所述运行结果；

当未请求到运行结果时，结束向服务器查询指定任务的任务状态的操作。

优选地，还包括：

当未接收到服务器针对所述查询请求返回的响应消息时，查找上一次的查询时间；

当经过上一次的查询时间时，返回执行所述向服务器发送针对指定任务的任务状态的查询请求的步骤；

当向服务器查询指定任务的任务状态的次数超过预设的次数阈值时，结束向服务器查询指定任务的任务状态的操作；

针对结束查询任务的操作生成提示信息。

优选地，还包括：

向服务器发送任务的生成请求；

当接收到服务器针对所述生成请求返回的响应消息时，判断任务是否生成；

若是，则将生成的任务的任务标识写入预设的消息队列中；

若否，则从所述响应消息中提取失败提示信息，展示所述失败提示信息。

本申请实施例还公开了一种任务状态的查询装置，包括：

查询请求发送模块，用于向服务器发送针对指定任务的任务状态的查询请求；

任务状态当前模块，用于在接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；

查询时间设置模块，用于在所述任务状态为任务运行中时，根据所述响应消息设置下一次的查询时间；

计时模块，用于判断是否经过下一次的查询时间，若是，则返回调用所述查询请求发送模块。

优选地，所述查询请求发送模块包括：

任务标识变量查找子模块，用于查找在预设的消息队列中的任务标识；

请求发送子模块，用于向服务器发送查询所述任务标识对应的任务状态的请求。

优选地，所述查询时间设置模块包括：

日志长度计算子模块，用于计算所述响应消息中运行日志信息的日志长度；

第一设置子模块，用于按照所述日志长度设置下一次的查询时间。

优选地，所述第一设置子模块包括：

第一时间设置单元，用于在所述日志长度大于或等于第一长度阈值时，设置下一次的查询时间为第一时间；

第二时间设置单元，用于在所述日志长度大于或等于第二长度阈值、且小于第一长度阈值时，设置下一次的查询时间为第二时间；

第三时间设置单元，用于在所述日志长度小于第二长度阈值时，设置下一次的查询时间为第三时间；

其中，所述第一长度阈值大于所述第二长度阈值；

优选地，所述查询时间设置模块包括：

运行负载信息提取子模块，用于从所述响应消息中提取服务器的运行负载信息；

第二设置子模块，用于按照所述运行负载信息设置下一次的查询时间。

优选地，所述第二设置子模块包括：

第四时间设置单元，用于在所述运行负载信息为快速运行时，设置下一次的查询时间为第四时间；

第五时间设置单元，用于在所述运行负载信息为正常运行时，设置下一次的查询时间为第五时间；

第六时间设置单元，用于在所述运行负载信息为慢速运行时，设置下一次的查询时间为第六时间；

优选地，还包括：

第一提示信息生成模块，用于针对任务运行中的任务状态生成提示信息；

运行日志信息展示模块，用于展示所述响应消息中的运行日志信息。

优选地，还包括：

第二提示信息生成模块，用于在所述任务状态为任务运行成功时，针对任务运行成功的任务状态生成提示信息；

运行结果请求模块，用于向服务器请求所述任务的运行结果；

运行结果展示模块，用于在请求到运行结果时，展示所述运行结果；

第一查询结束模块，用于在未请求到运行结果时，结束向服务器查询指定任务的任务状态的操作。

优选地，还包括：

查询时间查找模块，用于在未接收到服务器针对所述查询请求返回的响应消息时，查找上一次的查询时间；

重查询模块，用于判断是否经过上一次的查询时间，若是，则返回调用所述查询请求发送模块；

第二查询结束模块，用于在向服务器查询指定任务的任务状态的次数超过预设的次数阈值时，结束向服务器查询指定任务的任务状态的操作；

第三提示信息生成模块，用于针对结束查询任务的操作生成提示信息。

优选地，还包括：

生成请求发送模块，用于向服务器发送任务的生成请求；

任务生成判断模块，用于在接收到服务器针对所述生成请求返回的响应消息时，判断任务是否生成；若是，则调用任务标识写入模块，若否，则调用失败提示信息提取模块；

任务标识写入模块，用于将生成的任务的任务标识写入预设的消息队列中；

失败提示信息提取模块，用于从所述响应消息中提取失败提示信息；

失败提示信息展示模块，用于展示所述失败提示信息。

本申请实施例包括以下优点：

本申请实施例在任务运行中时，可以从响应消息获知处理状态，从而基于当前的处理状态智能设置轮询的时间，实现动态轮询，避免了连续不断的请求冲垮服务器，同时，减少了获取任务状态的时间，减少延迟，提高实时性。

附图说明

图1是本申请的一种任务状态的查询方法实施例1的步骤流程图；

图2是本申请的一种任务状态的查询方法实施例2的步骤流程图；

图3是本申请的一种任务状态的查询方法实施例3的步骤流程图；

图4是本申请的一种任务状态的查询方法实施例4的步骤流程图；

图5是本申请的一种任务状态的查询装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种任务状态的查询方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101，向服务器发送针对指定任务的任务状态的查询请求；

在具体实现中，在服务器运行任务(Job)之后，可以向服务器查询该任务的任务状态。

例如，对于普通类的网站，如社交网站、微博等，用户在登录之后，通常要实时向网站的服务器查询用户的账号是否有新的消息、是否有新的通知、是否有新的留言等等。

又例如，对于大数据计算类的网站，可能要同时运行几个脚本代码(任务)，处理一些事情，比如统计总量、分类量，百分比、增长率。

而这些任务发送到底层服务器通过数据筛查、计算等过程，而且机器又是分布集群，一般是很慢的，不能实时返回结果，即异步运行。

因此，通常要运行一段时间，少则数分钟、多则数小时、甚至数天，查询下发的任务的进度及运行情况。

应用本申请实施例，在任务生成时，可以预先将任务的任务标识(如JobID、index(如果有，子任务序列号))缓存至消息队列中。

因此，可以查找在预设的消息队列中的任务标识(JobID)，进而，向服务器发送查询任务标识(JobID)对应的任务状态的请求。

由于消息队列中的JobID相互独立，因此，可以支持多任务同时查询任务状态。

在本申请实施例的一个示例中，可以基于Ajax(Asynchronous Javascript And XML，异步JavaScript和XML(标准通用标记语言的子集))向服务器查询任务状态。

Ajax就是对浏览器本身的特性(IE5.6浏览器为ActiveXObject，其他浏览器为XMLHttpRequest)做的封装，成为一个方法，目标是发送一个HTTP(Hypertext transfer protocol，超文本传送协议)请求，一般包含几个部分：

url:请求的URL(Uniform Resource Locator，统一资源定位符)；

data:请求的参数，如JobID；

timeout:超时时间，即距收到服务器响应的最大等待时间，超时则放弃该请求；

success:成功收到响应数据的处理函数；

error:请求各种异常的处理函数。

步骤102，当接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；

服务器若接收到了JobID，则可以查询该JobID对应Job的运行日志信息，通过响应消息返回。

其中，该运行日志信息中包括如下的一项或多项内容：

运行日志内容、日志长度、任务状态(任务运行中、任务运行成功、任务运行失败)、是否最后一个任务、是否有运行结果。

因此，若接收到服务器针对查询请求返回的响应消息，则可以读取运行日志信息，从日志运行信息中读取任务状态。

需要说明的是，对于任务的任务状态，也可以存储至消息队列中。

步骤103，当所述任务状态为任务运行中时，根据所述响应消息设置下一次的查询时间；

在本申请实施例中，若接收到服务器针对查询请求返回的响应消息，则可以执行successCallback流程。

在successCallback流程中，若任务状态为任务运行中，则表示该任务正在服务器处理，并未结束，因此，需要继续轮询。

在本申请实施例中，可以通过任务/服务器当前的运行信息智能设置下一次的查询时间，即距上次成功查询到任务状态时到再次发起查询请求时之间的时间长度，该查询时间可以是以秒为单位，也可以是以毫秒为单位，本申请实施例对此不加以限制。

对于下一次的查询时间，可以采用Javascript的setTimeout方法或setInterval方法设置定时器的方式计时。

在本申请的一个实施例中，步骤103可以包括如下子步骤：

子步骤S11，计算所述响应消息中运行日志信息的日志长度；

子步骤S12，按照所述日志长度设置下一次的查询时间。

任务在运作时会产生一个叫log的运行日志信息，每一行日志记载着日期、时间、使用者及动作等相关操作的描述。

在本申请实施例中，日志长度与下一次的查询时间可以成反比。

日志长度越长，则表示内容越多，服务器的操作越频繁，可能需要用户处理的事情就越多，因此，下一次的查询时间就越短，让用户及时了解任务的任务状态，及时进行应对。

在实际应用中，本领域技术人员可以根据实际情况(如经验值、业务情景等)设置相应的下一次查询时间的间隔等级、间隔值，以及日志长度的长度阈值等等。

对于时间等级，可以设置为任意N(N为正整数)个，对于间隔值，可以设置为1秒、200毫秒等等，对于日志长度，可以设置为任意N(N为正整数)个等级，字节为单位，如1000字节、100字节等等。

在本申请实施例的一个示例中，可以设置根据运行日志信息文本的长度决定设定三个时间间隔：

日志长度(X)	下一次的查询时间
		X≥largeLogLength	smallInterval
normalLogLength≤X＜largeLogLength	middleInterval
		X＜normalLogLength	largeInterval

具体而言：

当日志长度大于或等于第一长度阈值largeLogLength时，可以认为任务的运行状态为快速运行，为快速反应一定的任务运行情况，故需要快速进行反馈，可以设置下一次的查询时间为第一时间smallInterval(如1秒)。

当日志长度大于或等于第二长度阈值normalLogLength、且小于第一长度阈值largeLogLength时，可以认为任务运行情况一般，正常间隔查询任务状态即可，因此，可以设置下一次的查询时间为第二时间middleInterval(如2秒)；

当所述日志长度小于第二长度阈值normalLogLength时，可以认为任务为运行缓慢或任务等待中等情况，则可较大间隔后查询任务状态，设置下一次的查询时间为第三时间largeInterval(如3秒)；

其中，第一长度阈值大于所述第二长度阈值，第一时间小于第二时间，第二时间小于第三时间。

当然，上述基于日志长度设置查询时间的方式只是作为示例，在实施本申请实施例时，可以根据实际情况设置其他基于日志长度设置查询时间的方式，本申请实施例对此不加以限制。另外，除了上述基于日志长度设置查询时间的方式外，本领域技术人员还可以根据实际需要采用其它基于日志长度设置查询时间的方式，本申请实施例对此也不加以限制。

在本申请的另一个实施例中，步骤103可以包括如下子步骤：

子步骤S21，从所述响应消息中提取服务器的运行负载信息；

子步骤S22，按照所述运行负载信息设置下一次的查询时间。

服务器的运行负载信息或其他决定因素信息可以以状态位的形式反馈在响应消息中，如busyStatus。

在本申请实施例中，服务器的运行负载与下一次的查询时间可以成反比。

服务器运行负载越小，运行速度越快，可以有越多的资源去查询任务的任务状态，因此，下一次的查询时间越短，让用户及时了解任务的任务状态，及时进行应对。

对于时间等级，可以设置为任意N(N为正整数)个，对于间隔值，可以设置为1秒、200毫秒等等，对于运行负载信息，可以设置为任意N(N为正整数)个等级，如闲/忙，快速运行/正常运行/慢速运行等等。

在本申请实施例的一个示例中，可以设置根据服务器的运行负载状态决定设定三个时间间隔：

运行负载信息busyStatus	下一次的查询时间
		快速运行	smallInterval
正常运行	middleInterval
		慢速运行	largeInterval

具体而言：

当运行负载信息busyStatus为快速运行时，可以认为服务器的负载较低，可用资源较多，为快速反应一定的任务运行情况，故需要快速进行反馈，可以设置下一次的查询时间为第四时间smallInterval(如1秒)；

当运行负载信息busyStatus为正常运行时，可以认为服务器的负载正常，可用资源一般，正常间隔查询任务状态即可，因此，可以设置下一次的查询时间为第五时间middleInterval(如2秒)；

当运行负载信息busyStatus为慢速运行时，可以认为服务器的负载较高，可用资源较少，可以设置下一次的查询时间为第六时间largeInterval(如3秒)；

其中，第四时间小于第五时间，第五时间小于第六时间。

当然，上述基于运行负载信息设置查询时间的方式只是作为示例，在实施本申请实施例时，可以根据实际情况设置其他基于运行负载信息设置查询时间的方式，本申请实施例对此不加以限制。另外，除了上述基于运行负载信息设置查询时间的方式外，本领域技术人员还可以根据实际需要采用其它基于日志长度设置查询时间的方式，本申请实施例对此也不加以限制。

在本申请实施例中，可以针对任务运行中的任务状态生成提示信息，并展示响应消息中的运行日志信息，让用户了解该任务的运行情况。

其中，该提示信息可以基于Notification生成，可以在客户端(如浏览器)中某一位置、以窗口的方式展示。

该窗口无需用户关闭，自动在若干时间后关闭。

在所运行的任务的标题上加以背景颜色提示，一般为易于理解且醒目的颜色，如任务运行中的颜色为黄色。

此外，由于运行日志信息中的数据一般可以直接展示给用户，少数部分可以进行转换后再展示，有特殊要求的可作筛选、转换等等。

需要说明的是，由于可能并发查询多个任务的状态，在页面中可能存在两个或两个以上的提示信息，该提示信息的窗口位置错开，互不影响。

步骤104，判断是否经过下一次的查询时间，若是，则返回执行步骤101。

当定时器计时完成时，到达下一次的查询时间时，可以从消息队列中，查询该定时器对应的JobID，继续查询该JobID对应的任务的任务状态。

参照图2，示出了本申请的一种任务状态的查询方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤201，向服务器发送针对指定任务的任务状态的查询请求；

步骤202，当接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；

步骤203，当所述任务状态为任务运行成功时，针对任务运行成功的任务状态生成提示信息；

步骤204，向服务器请求所述任务的运行结果；

步骤205，当请求到运行结果时，展示所述运行结果；

步骤206，当未请求到运行结果时，结束向服务器查询指定任务的任务状态的操作。

在本申请实施例中，服务器返回的运行日志信息中，某一个字段表示任务运行成功，若检测到该字段，则可以表示任务运行成功。

在successCallback流程中，针对任务运行成功的任务状态，可以生成提示信息，让用户了解该任务的运行情况。

其中，该提示信息可以基于Notification生成，可以在客户端任务运行成功中某一位置、以窗口的方式展示。

该窗口无需用户关闭，自动在若干时间后关闭。

在所运行的任务的标题上加以背景颜色提示，一般为易于理解且醒目的颜色，如任务运行成功的颜色为绿色。

若识别任务运行成功，则可以向服务器发送JobId、index(如果有，子任务序列号)拉取任务的运行结果。

若请求到运行结果，则可以展示给用户。

而对于一些特别的任务，比如查询简要信息等，是没有任务运行结果的，严格来说，是将这些运行结果的信息放在运行日志信息中返回了。

因此，若未请求到运行结果，则可以直接结束查询操作，将消息队列中该任务相关的信息删除，如JobID、任务状态等。

参照图3，示出了本申请的一种任务状态的查询方法实施例3的步骤流程图，具体可以包括如下步骤：

步骤301，向服务器发送针对指定任务的任务状态的查询请求；

步骤302，当未接收到服务器针对所述查询请求返回的响应消息时，查找上一次的查询时间；

步骤303，判断是否经过上一次的查询时间，若是，则返回执行步骤301；

步骤304，当向服务器查询指定任务的任务状态的次数超过预设的次数阈值时，结束向服务器查询指定任务的任务状态的操作；

步骤305，针对结束查询任务的操作生成提示信息。

在本申请实施例中，若由于网络异常或者超时等原因，未接收到服务器针对查询请求返回的响应消息，则可以执行errorCallback流程。

在errorCallback流程中，可以重新对JobID设置定时器，时间为上一次的查询时间。

当定时器计时完成时，到达上一次的查询时间时，可以从消息队列中，查询该定时器对应的JobID，继续查询该JobID对应的任务的任务状态。

若查询次数超过预设的次数阈值maxTrytime，即当因异常情况重试时的最大尝试次数，则可以直接结束查询操作，将消息队列中该任务相关的信息删除，如JobID、任务状态等。

此外，还可以针对结束查询任务的操作生成提示信息。

该窗口无需用户关闭，自动在若干时间后关闭。

在所运行的任务的标题上加以背景颜色提示，一般为易于理解且醒目的颜色，如网络异常的颜色为红棕色。

参照图4，示出了本申请的一种任务状态的查询方法实施例4的步骤流程图，具体可以包括如下步骤：

步骤401，向服务器发送任务的生成请求；

步骤402，当接收到服务器针对所述生成请求返回的响应消息时，判断任务是否生成；若是，则执行步骤403，若否，则执行步骤404；

步骤403，将生成的任务的任务标识写入预设的消息队列中；

步骤404，从所述响应消息中提取失败提示信息；

步骤405，展示所述失败提示信息。

在本申请实施例中，客户端(如浏览器)可以将任务的相关条件信息发送至服务器。

例如，任务代码或者脚本文件(如SQL语句)、任务参数(如SQL的where条件)、其他辅助参数(如用户登录态)等。

服务器收到任务的相关信息，生成任务，并配置JobID，如果这个任务需要分隔成多个子任务，则会返回子任务个数给客户端(如浏览器)。

客户端(如浏览器)成功收到来自服务器的响应消息，判断是否生成任务成功。

以ajax为例，在请求成功发送(即返回200状态码)、响应消息中返回JobID时，则可以判断生成任务成功。

若生成任务成功，则可以将其JobID存储至缓存变量JobID中，并设置页面状态为执行中，运行按钮不可点击，显示一个等待图如菊花转圈圈，阻止用户二次点击执行，停止按钮可点击允许用户停止任务。

若生成任务失败，则可以提取失败提示信息并进行展示。

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

参照图5，示出了本申请的一种任务状态的查询装置实施例的结构框图，具体可以包括如下模块：

查询请求发送模块501，用于向服务器发送针对指定任务的任务状态的查询请求；

任务状态当前模块502，用于在接收到服务器针对所述查询请求返回的响应消息时，从所述响应消息中读取任务状态；

查询时间设置模块503，用于在所述任务状态为任务运行中时，根据所述响应消息设置下一次的查询时间；

计时模块504，用于判断是否经过下一次的查询时间时，若是，则返回调用所述查询请求发送模块501。

在本申请的一个实施例中，所述查询请求发送模块501可以包括如下子模块：

在本申请的一个实施例中，所述查询时间设置模块503可以包括如下子模块：

在本申请实施例的一个示例中，所述第一设置子模块可以包括如下单元：

其中，所述第一长度阈值大于所述第二长度阈值；

在本申请的另一个实施例中，所述查询时间设置模块503可以包括如下子模块：

在本申请实施例的一个示例中，所述第二设置子模块可以包括如下单元：

在本申请的一个实施例中，该装置还可以包括如下模块：

重查询模块，用于判断是否经过上一次的查询时间，若是，则返回调用所述查询请求发送模块501；

在本申请的一个实施例中，该装置还可以包括如下模块：

生成请求发送模块，用于向服务器发送任务的生成请求；

失败提示信息展示模块，用于展示所述失败提示信息。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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

Claims

1.一种任务状态的查询方法，其特征在于，包括：

向服务器发送针对指定任务的任务状态的查询请求；

2.根据权利要求1所述的方法，其特征在于，所述向服务器发送查询指定任务的任务状态的请求的步骤包括：

查找在预设的消息队列中的任务标识；

向服务器发送查询所述任务标识对应的任务状态的请求。

3.根据权利要求1所述的方法，其特征在于，所述根据所述响应消息设置下一次的查询时间的步骤包括：

计算所述响应消息中运行日志信息的日志长度；

按照所述日志长度设置下一次的查询时间。

4.根据权利要求3所述的方法，其特征在于，所述按照所述日志长度设置下一次的查询时间的步骤包括：

其中，所述第一长度阈值大于所述第二长度阈值；

5.根据权利要求1所述的方法，其特征在于，所述根据所述响应消息设置下一次的查询时间的步骤包括：

从所述响应消息中提取服务器的运行负载信息；

按照所述运行负载信息设置下一次的查询时间。

6.根据权利要求5所述的方法，其特征在于，所述按照所述运行负载信息设置下一次的查询时间的步骤包括：

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

针对任务运行中的任务状态生成提示信息；

展示所述响应消息中的运行日志信息。

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

向服务器请求所述任务的运行结果；

当请求到运行结果时，展示所述运行结果；

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

针对结束查询任务的操作生成提示信息。

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

向服务器发送任务的生成请求；

若是，则将生成的任务的任务标识写入预设的消息队列中；

11.一种任务状态的查询装置，其特征在于，包括：

12.根据权利要求11所述的装置，其特征在于，所述查询时间设置模块包括：

13.根据权利要求11所述的装置，其特征在于，所述查询时间设置模块包括：