一种异步任务处理方法及系统与流程

本公开涉及通信及大数据领域，尤其涉及一种异步任务处理方法及系统。

背景技术：

随着业务的发展，业务的处理逻辑越来越复杂，导致业务请求的处理时间不断增加，响应速度越来越慢。除此之外，业务访问量也会快速增加，这要求系统必须能够处理高并发场景，否则系统随时都有崩溃的可能。

为了提高处理效率，一种方案是基于kafka与mysql的结合实现业务处理任务的异步处理，kafka负责缓存任务请求，mysql负责记录任务的处理状态。该方案中，上层应用的任务请求先缓存到kafka，并在mysql中记录任务的当前状态。任务的每次状态变更都记录在mysql中。上层应用可以通过访问数据库查询任务所处的状态。虽然mysql可以集群式部署，但是其集群式比较复杂，所以一般都是单节点部署。因此该方案不可避免地会出现单节点故障，而且单节点的处理速度有限，当业务量快速增加时，mysql将成为整个系统的性能瓶颈。此外，后期业务量增加时，一般是选择分库、分表的方式进行扩展，但是分库分表操作比较复杂，开发维护成本比较高。

技术实现要素：

有鉴于此，本公开提供一种异步任务处理方法及系统，用于解决现有大数据系统任务处理效率不高、扩展性不佳的技术问题。

基于本公开实施例，本公开提供了一种异步任务处理方法，该方法包括：

请求处理层接收应用层发送的任务创建请求，并创建任务；

请求处理层将任务加入缓冲层中的分布式流处理平台中的任务队列，并在缓冲层中的分布式搜索引擎中创建所述任务对应的任务状态记录；

任务处理层从所述任务队列中提取任务并执行任务；

任务处理层负责更新所述分布式搜索引擎中所述任务的任务状态记录。

基于本公开实施例，进一步地，所述方法还包括：

为每个任务状态分配一个版本号；

当缓冲层的分布式搜索引擎接收到更新任务状态请求时，分布式搜索引擎先校验所述更新任务状态请求中携带的任务状态版本号是否与所述任务状态记录中的任务状态版本号一致，如果一致则更新任务状态并根据任务状态版本号的切换规则更新任务状态版本号，否则拒绝更新任务状态。

基于本公开实施例，进一步地，所述任务的任务状态分为多个级别，每一级任务状态具有相同的任务状态版本号；所述的任务状态版本号的切换规则为：上一级任务状态版本号只能向下一级任务状态版本号切换。

基于本公开实施例，进一步地，该方法还包括：

所述请求处理层接收到应用层的任务状态查询请求时，从所述分布式搜索引擎中读取所述任务的任务状态记录，并将查询结果反馈给所述请求处理层。

基于本公开实施例，进一步地，该方法还包括：

当所述请求处理层接收到应用层的任务取消请求请求取消所述任务时，所述请求处理层指令所述分布式搜索引擎更新所述任务的任务状态记录为取消状态；

当任务超时需要终止所述任务时，所述请求处理层指令所述任务处理层终止所述任务的执行，所述任务处理层还用于请求所述分布式搜索引擎更新所述任务的任务状态记录为处理失败状态。

基于本公开实施例，本公开还提供一种异步任务处理系统，该系统包括：

应用层，用于基于业务需求发起任务创建请求以及查询任务状态请求；

请求处理层，用于响应应用层的任务创建请求并指令缓冲层创建任务，以及响应应用层的任务状态查询请求从缓冲层读取任务状态并反馈处理结果；

缓冲层，用于通过分布式流处理平台的任务队列缓存任务，以及通过分布式搜索引擎记录任务状态；

任务处理层，用于从缓冲层获取任务并实际执行任务，并通过发送更新任务状态请求指令缓冲层更新任务状态。

基于本公开实施例，进一步地，所述请求处理层包括：

任务提交模块，用于在接收到应用层的任务创建请求后创建相应的任务，并将任务封装成分布式流处理平台消息格式将任务发送到分布式流处理平台，以将任务插入到分布式流处理平台中的任务执行队列当中；在将任务成功插入到分布式流处理平台中的任务执行队列中后，还用于通过创建任务状态记录消息指令分布式搜索引擎创建对应的任务状态记录；

任务查询模块，用于在接收到应用层发送的任务状态查询请求时通过向分布式搜索引擎发送查询任务状态消息从分布式搜索引擎查询相应任务的任务状态并将查询结果反馈给应用层。

基于本公开实施例，进一步地，每个任务状态具有一个任务状态版本号，所述缓冲模块中的分布式搜索引擎为每个任务建立一个任务状态记录，任务状态记录中包含任务状态版本号字段；

所述分布式搜索引擎接收到更新任务状态请求时，先取出任务状态记录中记录的第一任务状态版本号，然后验证更新任务状态请求中携带的任务状态版本号是否与所述第一任务状态版本号一致，如果一致则更新任务状态并根据任务状态版本号的切换规则更新任务状态版本号，否则拒绝更新任务状态。

基于本公开实施例，进一步地，所述请求处理层还包括：

任务取消模块，用于接收到应用层的任务取消请求时，指令所述分布式搜索引擎更新所述任务的任务状态记录为取消状态；

所述任务处理层，还用于在从所述分布式流处理平台的任务队列中取出任务时，指令所述分布式搜索引擎更新所述任务的任务状态记录为处理中状态，若更新任务状态失败，则不执行所述任务。

基于本公开实施例，进一步地，所述系统还包括：

超时处理模块，用于在任务超时需要终止所述任务时，指令任务处理模块终止所述任务的执行；

所述任务处理层，还用于在接收到终止任务执行的请求时，指令分布式搜索引擎更新所述任务的任务状态记录为处理失败状态。

本公开提供的异步任务处理系统分为四层，分别为应用层、请求处理层、缓冲层和任务处理层。请求处理层负责任务的提交、查询等操作，缓冲层使用分布式流处理平台缓存任务队列，使用分布式搜索引擎缓存任务状态记录。本公开中，采用异步方式实现任务的创建与处理，可以提高系统处理高并发请求的能力；采用基于版本号的免查询的状态更新机制更新任务状态，可以减少系统交互，提高系统处理效率。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开一实施例提供的异步任务处理系统的架构示意图；

图2为本公开一实施例提供的任务提交处理流程图；

图3为本公开一实施例提供的任务状态转换图；

图4为本公开一实施例提供的带任务状态版本号的任务状态转换图；

图5为本公开一实施例提供的任务处理层处理任务的流程图；

图6为本公开一实施例提供的一种异步任务处理方法的步骤流程图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为了提高业务系统的处理效率和性能的可扩展性，避免存储业务状态的数据库的单节点故障，本公开提出了一种高可用、可横向扩展的异步任务处理系统和方法。本公开提供的方案的基本思想是通过分布式流处理平台，例如kafka，缓存任务请求，同时使用分布式搜索引擎，例如elasticsearch(以下简称es)，记录任务状态，任务的状态变更实时同步到分布式搜索引擎当中，根据当前任务状态做相应处理。

图1为本公开一实施例提供的异步任务处理系统的架构示意图，该实施例中，分布式流处理平台以kafka集群为例，分布式搜索引擎以elasticsearch为例，整体架构可分为4层：

第一层是应用层，应用层为系统的对外接口层，用于基于业务需求发起任务创建请求以及查询任务状态，例如发送任务创建请求以请求创建任务，发送任务状态查询请求以查询任务状态。此外，应用层还用于发送任务取消请求以取消不需要继续执行或还未执行的任务等。

第二层是请求处理层，用于响应应用层的任务创建请求并指令缓冲层创建任务，以及响应应用层的任务状态查询请求从缓冲层读取任务状态并反馈处理结果。

请求处理层包含任务提交模块、任务查询模块。任务提交模块在接收到应用层的任务创建请求后创建相应的任务，并将任务封装成kafka消息(挂载任务消息)将任务发送到kafka集群，以将任务插入到kafka集群中的任务执行队列当中，同时在将任务成功插入到kafka集群中的任务执行队列中后，任务提交模块还通过创建任务状态记录消息在es集群中创建对应的任务状态记录。任务查询模块接收到应用层发送的任务状态查询请求时通过向es集群发送查询任务状态消息从es集群查询相应任务的任务状态并将查询结果反馈给应用层。

请求处理层还可进一步包括任务取消模块和超时处理模块。任务取消模块用于取消不需要继续执行或还未执行的任务。超时处理模块负责将长时间未处理或未处理完成的任务设置为失败状态。

第三层是缓冲层，用于通过分布式流处理平台的任务队列缓存任务，以及通过分布式搜索引擎记录任务状态。例如，缓冲层包含kafka集群与es集群两个组件，kafka集群负责缓存待处理的任务请求，es集群负责记录任务的当前处理状态。

第四层是任务处理层，用于实际执行任务。任务处理层从缓冲层获取任务并实际执行任务，并通过发送更新任务状态请求指令缓冲层更新任务状态。该层可根据具体业务需求对接不同的任务处理模块。

图2为本公开一实施例提供的任务提交处理流程图，任务提交模块处理流程步骤如下：

步骤201.任务提交模块接收到应用层发送的任务创建请求后根据请求中的任务信息创建任务，然后将任务封装成kafka消息格式发送给缓冲层的kafka集群，将消息插入kafka集群的任务队列中。

步骤202.根据kafka集群反馈的结果判断是否成功将任务插入到kafka集群的任务队列当中，如果插入失败执行步骤205，如果插入成功则执行步骤203。

步骤203.向es集群发送创建任务状态记录请以指令es集群建立任务对应的任务状态记录。

步骤204.向应用层反馈任务创建成功响应。

步骤205.向应用层反馈任务创建失败响应。

图3为本公开一实施例提供的任务状态转换图。本公开提供的异步处理系统中的任务的处理采用异步处理模式，在整个任务处理过程中，任务会经历多种状态，该实施例中任务状态包含五种状态：待处理、处理中、处理成功、处理失败和取消。

当任务被提交到kafka的任务队列中后，任务状态是“待处理”；当任务被取消后，任务状态是“取消”；当任务从任务队列中取出被执行时，任务状态变更为“处理中”；当任务成功执行完成后状态变更为“处理成功”，当任务执行失败后状态变更为“处理失败”。

任务查询模块主要负责访问es查询任务状态，并将查询结果返回给上层应用。任务处理模块需要根据任务处理结果更新es集群中的任务状态记录，在更新任务状态时，任务处理模块需要校验当前任务的状态是否满足更新条件。从图3分析可知，只有处于“待处理”状态的任务，才能被更新为“取消”或者“处理中”。因此将任务更新为“取消”或者“处理中”时需要校验任务的当前状态是否为“待处理”。至于“处理成功”和“处理失败”状态的更新则不需要校验，因为任务的处理流程是顺序进行的，只有任务被更新为“处理中”后，才可能发生后续处理。所以将任务更新为这两种状态之前，任务必然是处于“处理中”状态的。

本公开一实施例，为了提高任务处理模块大量并发执行的任务对任务状态记录并发更新的效率，提供了一种基于版本号的免查询的状态更新机制，该机制的基本思路为：为避免在更新es中的任务状态时需要先查询es中的任务状态的步骤，将状态的验证和更新步骤合并为一个步骤，以提高并行处理的效率。为达到该目的，本公开一实施例中，为每个任务状态分配一个版本号，es中的版本号字段可以用于记录该任务状态版本号，当需要更新任务状态时，es首先取出任务的任务状态记录中记录的第一任务状态版本号，然后验证更新任务状态请求中携带的任务状态版本号是否与第一任务状态版本号一致，如果一致则说明任务状态验证通过，es更新任务状态并根据任务状态版本号的切换规则将第一任务状态版本号切换为下一级任务状态版本号，如果任务状态验证未通过，则拒绝更新任务状态记录。

图4为本公开一实施例提供的带任务状态版本号的任务状态转换图，该实施例中建立任务状态与任务状态版本号之间的映射关系。“待处理”状态是任务状态记录的初始状态，其对应版本号的初始值“1”。“处理中”和“取消”状态都是基于“待处理”的下一任务状态，因此其版本号为“2”；“处理成功”“处理失败”状态是基于“处理中”状态的更新，因此其版本号为“3”。基于图4可以看出，所有任务状态可以分为三级，第一级为“待处理状态”，其任务状态版本号为1，第二级包括“处理中”和“取消”，其任务状态版本号都为2。第三级包括“处理成功”和“处理失败”，其任务状态版本号都为3。既定的任务状态版本号的切换规则只能为从1到2再到3。基于上述规则，“取消”和“处理中”状态的更新需要校验任务状态是否处于“待处理”状态，“待处理”状态的版本号为“1”，那么就可以通过校验版本号是否为“1”判断任务状态是否为“待处理”状态。

为了灵活处理任务，本公开一实施例设计了任务取消模块，以满足任务取消的需求。任务取消涉及到任务状态的更新，当任务被取消后，需要更新es集群中的任务状态记录，因此，任务取消前需要判断任务是否处于“待处理”状态，只有处于“待处理”状态的任务才可以被取消。按照常规设计，应该向es发送任务状态查询请求以读取任务状态，如果状态为“待处理”，然后再向es发送任务状态更新请求，将任务状态更新为“取消”状态。在这个过程中，需要与es交互两次，一次查询和一次更新。

使用本公开提供的基于版本号的免查询的状态更新机制，可以仅用一次交互即可完成任务的取消。具体流程如下：假设es集群中任务状态记录中记录的当前任务状态为“待处理”状态，其对应的任务状态版本号为“1”，当es集群接收到的更新任务状态请求为任务取消请求时，es集群会首先校验任务取消请求中携带的任务状态版本号是否为“1”，如果是则更新任务状态记录并切换任务状态版本号为下一状态，否则拒绝更新任务状态。根据图4的状态切换图，任务状态版本号为“1”就是代表了“待处理”状态，所以es集群的版本校验结果是与状态校验一致的，因此不再需要通过查询请求校验状态，只需要在更新任务状态的请求中携带版本号即可完成校验与更新。

基于本公开提供的一种基于版本号的免查询的状态更新机制，在需要更新es集群中的任务状态记录时，可在任务状态更新请求中携带任务状态版本号，es集群可自动根据请求中携带的任务状态版本号进行状态切换规则的校验，避免了在状态更新前通过单独的消息进行状态查询和在请求侧进行校验的步骤，请求更新状态的模块通过一个任务状态更新请求即可完成任务状态校验和任务状态更新的操作，省去了更新前的状态查询步骤，减少与es的交互次数，提高了状态更新的效率。

在实际业务处理过程中，可能有部分任务一直未被处理或未处理完成。为了处理该类任务，本公开一实施例提供了超时处理模块，该模块用于将长时间未被处理或未处理完成的任务强制终止并设置为“处理失败”状态。任务状态记录中保存了任务状态的更新时间，可以通过该时间判断任务是否超时。任务超时模块会定期扫描状态记录，将超时的任务设置为“处理失败”状态。

图5为本公开一实施例提供的任务处理层处理任务的流程图，任务处理模块负责从缓冲层的kafka集群中的任务队列中取出待处理的任务，并交付给负责实际处理业务逻辑的具体的子任务处理模块去处理。具体处理流程如下：

步骤501.从任务队列中提取出任务请求；

该步骤由任务处理模块通过接口或任务提取消息从缓冲层的kafka集群中读取在任务队列中等待处理的任务。

步骤502.将任务状态更新为“处理中”，如果更新失败代表该任务已取消，结束处理；如果更新成功，则执行步骤503。

该步骤由任务处理模块通过任务状态更新消息指示es集群更新任务状态记录，消息中需要携带“处理中”对应的任务状态版本号。

步骤503.将任务交付给具体子处理模块进行处理，并在任务处理完成后判断任务处理是否成功，若成功则执行步骤504，否则执行步骤505。

步骤504.任务处理完成后，如果执行成功则将任务状态更新为“处理成功”。

步骤505.任务处理完成后，如果执行失败则将任务状态更新为“处理失败”。

本公开一实施例中，任务处理模块作为任务的消费者取出任务后，不会立即执行任务，而是先判断该任务是不是处于“待处理”状态，因为该任务有可能已被取消，对于已取消的任务无须再处理。和任务取消模块的设计类似，采用任务状态版本号校验代替状态校验，仅与es交互一次就可完成状态的校验与更新。只有处于“待处理”状态才能被更新为“处理中”，因此在更新请求中同样也是携带版本号“1”。

本公开提供的任务处理方法采用异步处理模式，可以适应业务逻辑复杂度的变化，保证快速响应，同时有效处理高并发问题。与此同时，使用es集群替换mysql，借助es的分布式部署，实现了整个系统的高可用；借助es集群的快速查询与写入，提升了系统的处理速度。此外，es可以根据需要灵活增加分片，当业务量增加时，可以通过增加分片数量实现快速扩展，操作十分简洁，开发维护成本较低。

图6为本公开一实施例提供的一种异步任务处理方法的步骤流程图，基于上述异步任务处理系统架构，该方法包括：

步骤601.请求处理层接收应用层发送的任务创建请求，创建任务；

步骤602.请求处理层将任务加入缓冲层中的分布式流处理平台中的任务队列，并在缓冲层中的分布式搜索引擎中创建所述任务对应的任务状态记录；

步骤603.任务处理层从所述任务队列中提取任务并执行任务；

步骤604.任务处理层负责更新所述分布式搜索引擎中所述任务的任务状态记录。

本公开一实施例中，为每个任务状态分配一个版本号；当缓冲层的分布式搜索引擎接收到更新任务状态请求时，分布式搜索引擎先校验所述更新任务状态请求中携带的任务状态版本号是否与所述任务状态记录中的任务状态版本号一致，如果一致则更新任务状态并根据任务状态版本号的切换规则更新任务状态版本号，否则拒绝更新任务状态。

本公开一实施例中，任务的任务状态分为多个级别，每一级任务状态具有相同的任务状态版本号。任务状态版本号的切换规则为：上一级任务状态版本号只能向下一级任务状态版本号切换。

本公开一实施例中，请求处理层在接收到应用层的任务状态查询请求时，从分布式搜索引擎中读取所述任务的任务状态记录，并将查询结果反馈给请求处理层。

本公开一实施例中，请求处理层在接收到应用层的任务取消请求时，指令分布式搜索引擎更新所述任务的任务状态记录为取消状态；任务处理层在从所述分布式流处理平台的任务队列中取出任务时，指令所述分布式搜索引擎更新所述任务的任务状态记录为处理中状态，若更新任务状态失败，则不执行所述任务。

本公开一实施例中，在任务超时需要终止所述任务时，请求处理层指令任务处理层终止所述任务的执行。任务处理层在接收到终止任务执行的请求时，指令分布式搜索引擎更新所述任务的任务状态记录为处理失败状态。

以上所述仅为本公开的实施例而已，并不用于限制本公开。对于本领域技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。