任务处理方法、装置及系统和任务状态交互方法

技术领域

本申请涉及但不限于计算机技术，尤指一种任务处理方法、装置及系统和任务状态交互方法。

背景技术

对某个资源或某批资源进行某种操作的过程称之为任务。任务由外部提交，并在系统中处理，通常耗时较长。对于任务本身而言，是各自独立的，任务与任务之间没有什么关系，不适合处理完一个任务之后再处理下一个任务。

对于资源操作有批量任务的场景，比如批量创建资源即接收到的任务包括：创建资源1、创建资源2...创建资源n，这里，将创建资源1的任务称为子任务1、将创建资源2的任务称为子任务2...将创建资源n的任务称为子任务n，也就是说，根据批量任务批量处理的不同资源，将任务自然分为对应不同资源的子任务。相关技术中的任务处理方法，一种是，串行执行方法即一个资源、一个资源地创建，显然，这种任务处理方法会导致任务操作时间过长；另一种是，对各资源的创建是并行执行的，但是，这种方式对用户操作不透明，任务处理状态是无法被方便监测的，也就是说，资源创建过程的状态对用户是不透明的。这些状态可以包括如待处理、处理中、处理成功、处理失败、终结等，其中，待处理、处理中为不稳定状态，随着任务处理会变迁到其他状态，而处理成功、处理失败、终结为稳定状态，没有外界参与的情况下，状态不再变化。

从相关技术提供的任务处理方法来看，要么效率低，要么会由于任务状态的不透明而导致无法让用户知道此次对这批资源的操作中有多少是成功的，多少是失败的，这样也就无法对任务进行重试，也就是说任务执行的成功率是没法保证的。

发明内容

本申请提供一种任务处理方法、装置及系统和任务状态交互方法，能够提升任务执行效率，同时保证任务执行的成功率。

本发明实施例提供了一种任务处理方法，包括：

获取接收到的待执行的第一任务的任务编号，将所述第一任务拆分成至少两个子任务；

获取接收到的第一任务包括的各子任务的子任务编号；

根据所述子任务编号获取并记录各子任务的状态，根据子任务的状态更新所述第一任务的状态。

在一种示例性实例中，所述方法还包括：

控制所述子任务处理，在所述子任务的处理过程中，当所述子任务的处理时长超过预设处理时长，结束该子任务的执行，并标记该子任务的状态为失败状态。

在一种示例性实例中，所述方法还包括：

对于所述子任务的完成时状态为失败状态的子任务，返回所述控制子任务处理的步骤。

在一种示例性实例中，所述方法还包括：

判断出所述子任务的完成时状态为失败状态的子任务为具有不可重入的特点的子任务，则将该子任务的状态标记为终结。

在一种示例性实例中，所述控制子任务处理，包括：

通过控制多进程或多线程来实现所述子任务的并发执行；或者，

通过分布式系统来实现所述子任务的并发执行。

在一种示例性实例中，所述根据子任务编号获取并记录各子任务的状态，包括：

按照预先设置的询问周期，根据所述子任务编号定时询问所述子任务的状态，并记录得到的子任务的实时状态。

在一种示例性实例中，所述根据子任务编号获取并记录各子任务的状态，包括：

接收上报的所述子任务的状态，并根据所述子任务编号记录得到的子任务的实时状态。

在一种示例性实例中，所述根据子任务的状态更新第一任务的状态，包括：

当所述第一任务包括的所有子任务的状态都处于稳定状态时，将所述第一任务的状态标记为完成状态或者部分失败状态。

本申请还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项所述的任务处理方法。

本申请又提供了一种用于实现任务处理的装置，包括存储器和处理器，其中，存储器中存储有以下可被处理器执行的指令：用于执行上述任一项所述的任务处理方法的步骤。

本申请再提供了一种任务处理系统，包括：第一节点、以及与第一节点连接的若干个第二节点；其中，

第一节点，用于获取接收到的第一任务的任务编号，将第一任务拆分成至少两个子任务；获取接收到的第一任务包括的各子任务的子任务编号；下发第一任务包括的各子任务到第二节点；在子任务处理过程中，根据子任务编号获取并记录各子任务的状态，根据子任务的状态更新第一任务的状态；

第二节点，用于处理接收到的子任务；在子任务的处理过程中，提供子任务的状态。

在一种示例性实例中，所述系统还包括：第三节点；

第三节点，用于利用所述任务编号和/或所述子任务编号，通过人机交互界面获知所述第一任务和/或所述子任务的状态。

在一种示例性实例中，所述第一节点还用于：

下发所述子任务处理时，启动定时时长为预设处理时长的定时器，在定时器超时时，如果所述子任务的状态还不能达到稳定状态，向该子任务所在的第二节点发送结束该子任务执行的指令，并标记该子任务的状态为失败状态；相应地，

所述第二节点还用于：接收到来自所述第一节点的结束子任务执行的指令，结束该子任务的执行。

在一种示例性实例中，所述第一节点还用于：对所述子任务的完成时状态为失败状态的子任务重新发起所述处理。

在一种示例性实例中，所述第一节点还用于：判断出所述子任务的完成时状态为失败状态的子任务为具有不可重入的特点的子任务，则将该子任务的状态标记为终结。

在一种示例性实例中，所述第一节点中的在子任务处理过程中，根据子任务编号获取并记录各子任务的状态，包括：

按照预先设置的询问周期，根据所述子任务编号定时向所述第二节点询问子任务的状态，并记录得到的子任务的实时状态；或者，接收所述第二节点上报的子任务的状态，并根据所述子任务编号记录得到的子任务的实时状态。

在一种示例性实例中，所述第二节点中的在子任务的处理过程中，提供子任务的状态，包括：

接收到来自所述第一节点的询问子任务的状态的询问请求，向所述第一节点返回子任务的当前状态；或者，在子任务状态发生变化时或者在预先设置的上报周期到来时，通过上报消息将子任务的当前执行状态上报给所述第一节点。

本申请又提供了一种任务状态交互方法，包括：

接收用户提交执行第一任务的请求，为所述第一任务分配任务编号；获取所述第一任务包括的各子任务的子任务编号及对应的任务状态；

根据第一任务的编号查询并显示第一任务的状态，所述第一任务的状态由对应的子任务的状态确定。

在一种示例性实例中，所述第一任务包括：实例的启停、创建、释放。

在一种示例性实例中，所述任务的状态包括：创建、启动、停止、重启、释放。

本申请提供包括：获取接收到的待执行的第一任务的任务编号，将第一任务拆分成至少两个子任务；获取接收到的第一任务包括的各子任务的子任务编号；根据子任务编号获取并记录各子任务的状态，根据子任务的状态更新第一任务的状态。通过本申请，提升了任务执行效率，而且保证了任务执行的成功率。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。

图1为本申请任务处理方法的实施例的流程图；

图2为本申请任务处理系统的实施例的组成架构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在本申请一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1为本申请任务处理方法的实施例的流程图，如图1所示，包括：

步骤100：获取接收到的待执行的第一任务的任务编号，将所述第一任务拆分成至少两个子任务。

在一种示例性实例中，获取第一任务编号，可以包括：

可以预先设置第一任务对应的任务编号；或者，也可以按照预先设置的规则，在接收到第一任务时，生成第一任务对应的任务编号。

对于不同的任务，任务编号是唯一的，只要能区分出不同的任务即可。比如：对于任务A，任务编号可以为A；对于任务B，任务编号可以为B等等。

步骤101：获取接收到的第一任务包括的各子任务的子任务编号。

在一种示例性实例中，获取子任务编号，可以包括：

可以预先设置各子任务的子任务编号；或者，也可以按照预先设置的规则，在接收到第一任务时，生成各子任务的子任务编号。

对于不同的子任务，子任务编号是唯一的，只要能区分出是属于某一个任务中的不同子任务即可。比如：对于任务A，任务编号可以为A，任务A包括子任务1、子任务2…子任务n，那么，子任务1的子任务表示可以为A1，子任务2的子任务表示可以为A2…子任务n的子任务表示可以为An等等。

本申请通过对任务(即第一任务)和任务包括的子任务进行编号，为后续的任务执行过程的监测提供了查找基础。

步骤102：根据子任务编号获取并记录各子任务的状态，根据子任务的任务状态更新第一任务的状态。

在一种示例性实例中，步骤102之前还包括：控制子任务处理，并将接收到的第一任务的状态记录为处理中。

在一种示例性实例中，可以通过控制多进程或多线程来实现子任务的并发执行。

在一种示例性实例中，可以通过分布式系统来实现子任务的并发执行。比如：分布式系统中作为管理控制的节点(可以称为第一节点或控制节点)将子任务下发给进行任务处理的若干节点(可以称为第二节点或计算节点)，由计算节点实现对子任务的并行执行。

在一种示例性实例中，第一任务的状态与第一任务的任务编号是相关联的。这样，根据任务编号可以方便地获知第一任务的实时状态。

本步骤中对第一任务包括的子任务的并发处理，提升了任务执行效率。

在一种示例性实例中，本步骤中的根据子任务编号获取并记录各子任务的状态，可以包括：

按照预先设置的询问周期，根据子任务编号定时询问子任务的状态，并记录得到的子任务的实时状态。

举个例子来看，以通过分布式系统来实现子任务的并发执行为例，控制节点会按照预先设置的周期，向计算节点发送询问请求，而计算节点会将询问请求对应的子任务的当前状态通过如询问响应等反馈给控制节点。需要说明的是，针对不同的子任务，可以有相同的询问周期，也可以有不同的询问周期。

在一种示例性实例中，本步骤中的根据子任务编号获取并记录各子任务的状态，可以包括：

接收上报的子任务的状态，并根据子任务编号记录得到的子任务的实时状态。

举个例子来看，以通过分布式系统来实现子任务的并发执行为例，计算节点可以在子任务状态发生变化时或者在预先设置的上报周期到来时，通过上报消息将子任务的当前执行状态上报给控制节点。

在一种示例性实例中，本步骤中的根据子任务的状态更新第一任务的状态，可以包括：

当第一任务包括的所有子任务的状态都是处于稳定状态，比如完成状态或失败状态时，将第一任务的状态标记为完成状态或者部分失败状态。

在一种示例性实例中，子任务的状态与子任务的子任务编号是相关联的。这样，根据子任务编号可以方便地获知子任务的实时状态。

本步骤中，由于任务状态是透明的，用户知道此次对这批资源的操作中有多少是成功的，多少是失败的，清楚如何对任务进行重试，这样，保证了任务执行的成功率。

综上所述，本申请任务处理方法，提升了任务执行效率，而且保证了任务执行的成功率。

由于本申请任务处理方法中，对第一任务和任务包括的各子任务都生成有编号，而且，在第一任务的处理过程中，都会记录任务和各子任务的实时执行状态，因此，本申请还可以包括：

利用任务编号和/或子任务编号，通过人机交互界面可以轻松获知任务和/或子任务的状态。也就是说，本申请任务处理方法对用户操作是透明的，实现了任务处理状态的方便监测。

在一种示例性实例中，本申请任务处理方法，还包括：

在子任务处理过程中，如果到达预设处理时长，子任务还没有达到稳定状态，也就是说，子任务的处理时长超过了对应该子任务的任务类型的预设处理时长(每种子任务都有最大处理上限时长)，那么，强制结束该子任务的执行，并标记该子任务的状态为失败状态。

举个例子来看，以通过分布式系统来实现子任务的并发执行为例，在控制节点下发子任务并行处理时，启动定时时长为预设处理时长的定时器，在定时器超时时，该子任务的状态还不能达到稳定状态如完成状态或失败状态，那么，控制节点可以向该子任务所在的计算节点发送结束该子任务执行的指令，以强制结束该子任务的执行，并标记该子任务的状态为失败状态。

需要说明的是，对应不同子任务的预设处理时长可以相同，也可以不同。

本申请任务处理方法，还包括：

对子任务的完成时状态为失败状态的子任务重新发起并发处理，并从步骤101中的将任务的状态标记为处理中，开始继续执行本申请任务处理方法。

本申请任务处理方法，还包括：

判断出子任务的完成状态为失败状态的子任务为具有不可重入的特点的子任务，则将该子任务的状态标记为终结。这样，这类子任务就不会再被重试了，节省了无谓的尝试，从而节约了资源。每个子任务的业务特性决定了该子任务是否具有不可冲入的特点。比如：某些子任务是将资源标记为欠费状态，如果这个子任务由于某些情况失败了，那么，能不能重试(即是否可重入)是要根据该资源的当前状态决定的，要是用户发生了缴费的行为，就会将这个失败的任务置为终结，以防止这个子任务被意外启动。

本申请还提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一项的任务处理方法。

本申请再提供一种实现任务处理的装置，包括存储器和处理器，其中，存储器中存储有以下可被处理器执行的指令：用于执行上任一项所述的任务处理方法的步骤。

本申请还提供一种任务状态交互方法，至少包括：

接收用户提交执行第一任务的请求，为所述第一任务分配任务编号；获取所述第一任务包括的各子任务的子任务编号及对应的状态；

根据第一任务的编号查询并显示第一任务的状态，所述第一任务的状态由对应的子任务的状态确定。

在一种示例性实例中，所述第一任务包括但不限于：实例的启停、创建、释放。

在一种示例性实例中，所述任务的状态包括但不限于：创建、启动、停止、重启、释放。

图2为本申请任务处理系统的实施例的组成架构示意图，如图2所示，至少包括第一节点、以及与第一节点连接的若干个第二节点；其中，

第一节点，用于获取接收到的第一任务的任务编号，将第一任务拆分成至少两个子任务；获取接收到的第一任务包括的各子任务的子任务编号；下发第一任务包括的各子任务到第二节点；在子任务处理过程中，根据子任务编号获取并记录各子任务的状态，根据子任务的状态更新第一任务的状态；

第二节点，用于处理接收到的子任务；在子任务的处理过程中，提供子任务的状态。

第一节点与若干个第二节点形成分布式系统。第二节点的数量与子任务的个数有关，比如：第二节点的数量与第二节点的任务负载有关，如果单一子任务需要的计算等资源高，那么，就需要更多的第二节点来分担处理压力。同时，如果拆分出的任务数过多，那么也需要更多的节点来处理。对于实际系统来说，就是看综合的系统负载，负载高就会用更多的机器(即更大数量的第二节点)来分担。

在一种示例性实例中，第一节点中的在子任务处理过程中，根据子任务编号并记录获取各子任务的状态，包括：

按照预先设置的询问周期，根据子任务编号定时向第二节点询问子任务的状态，并记录得到的子任务的实时状态；或者，接收第二节点上报的子任务的状态，并根据子任务编号记录得到的子任务的实时状态。

在一种示例性实例中，第二节点中的在子任务的处理过程中，提供子任务的状态，包括：

接收到来自第一节点的询问子任务的状态的询问请求，向第一节点返回子任务的当前状态；或者，在子任务状态发生变化时或者在预先设置的上报周期到来时，通过上报消息将子任务的当前执行状态上报给第一节点。

本申请任务处理系统，提升了任务执行效率，而且保证了任务执行的成功率。

在一种示例性实例中，第一节点还用于：

下发子任务处理时，启动定时时长为预设处理时长的定时器，在定时器超时时，该子任务的状态还不能达到稳定状态如完成状态或失败状态，向该子任务所在的第二节点发送结束该子任务执行的指令，并标记该子任务的状态为失败状态；相应地，

第二节点还用于：接收到来自第一节点的结束子任务执行的指令，强制结束该子任务的执行。

在一种示例性实例中，第一节点还用于：对完成时状态为失败状态的子任务重新发起并发处理。

在一种示例性实例中，第一节点还用于：判断出完成时状态为失败状态的子任务为具有不可重入的特点的子任务，则将完成状态为部分失败的任务的状态标记为终结。

在一种示例性实例中，图2所示的任务处理系统还包括：第三节点；

第三节点，用于利用任务编号和/或子任务编号，通过人机交互界面可以轻松获知任务和/或子任务的状态。也就是说，本申请任务处理系统实现了任务处理状态的方便监测。

需要说明的是，第三节点可以与第一节点为同一个节点；第三节点也可以是独立的、方便用户进行监测的节点，比如布置在监控机房中的一台设备，这种情况下，只要第一节点将任务和/或子任务的状态实时上报给第三节点即可。如何上报可以采用很多种方式，具体实现并不用于限定本申请的保护范围。这里强调的是，通过本申请实施例提供的实现方式，对用户来讲操作是透明的，实现了任务处理状态的方便监测。

虽然本申请所揭露的实施方式如上，但所述的内容仅为便于理解本申请而采用的实施方式，并非用以限定本申请。任何本申请所属领域内的技术人员，在不脱离本申请所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本申请的专利保护范围，仍须以所附的权利要求书所界定的范围为准。