CN110532082A - 一种基于任务预分配的任务申请装置和方法 - Google Patents

Abstract

本发明涉及一种的基于任务预分配的任务申请装置，包括存储器和处理器，存储器存储有指令，指令适于由处理器加载并执行以下步骤：客户端生成任务；判断生成的任务是否为高优先级任务；如当前任务是高优先级任务，则将当前任务放入高优先级队列中；如当前任务不是高优先级任务，则选择可执行任务的录入用户，将任务放入可执行任务的录入用户的预分配任务队列中；录入用户发起申请任务请求；如高优先级队列非空且存在录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；否则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；录入用户获取任务后，客户端将明细数据返回给录入用户。

Description

一种基于任务预分配的任务申请装置和方法

技术领域

本发明涉及一种基于任务预分配的任务申请装置和方法，属于办公自动化技术领域。

背景技术

任务申请系统主要用于票据的识别和录入业务。将单张票据中的字段进行切割分为多个录入任务，这些录入任务根据客户和类型，具有不同的优先级。录入用户向任务申请系统申请其有录入权限，并且优先级最高的录入任务进行录入。

现有任务申请系统主要是采用数据库事务锁表的方式来确保录入用户先申请到任务池中高优先级的录入任务，并且同一录入任务不会被其它录入用户申请到。

这种方式的局限性主要在如下方面：

1. 大部分的计算都放在录入用户发出录入任务申请后，如根据用户技能权限计算用户可以录入的任务集，当前该用户可以录入的最高优先级的任务集等；

2.录入用户的录入速度很快，申请任务的并发量很大，大量并发都会耗费大量的锁资源，导致在票据量高峰期的时候系统非常卡顿，严重影响了录入用户的录入效率；

3.传统关系型数据库随着数据量的增大，性能下降非常明显；然而录入任务数据量往往非常庞大，在几天时间就能达到千万级别，验证影响系统性能；

4.任务申请逻辑都写在数据库的存储过程中，由于传统关系型数据库本身单点的特性，无法做横向扩展，录入任务量大的情况下，无法通过增加硬件资源横向扩展系统的处理能力。

发明内容

为了解决上述现有技术中存在的问题，本发明提供一种

本发明的技术方案如下：

技术方案一

一种的基于任务预分配的任务申请装置，包括存储器和处理器，所述存储器存储有指令，所述指令适于由处理器加载并执行以下步骤：

客户端接收任务的明细数据并放入关系型数据库，并生成任务；

客户端判断生成的任务是否为高优先级任务；

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户。

进一步的，所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比。

进一步的，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

进一步的，所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。

技术方案二

一种基于任务预分配的任务申请方法，包括以下步骤：

客户端接收任务的明细数据并放入关系型数据库，并生成任务；

客户端判断生成的任务是否为高优先级任务；

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户。

进一步的，所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比。

进一步的，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

进一步的，所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。

本发明具有如下有益效果：

1、本发明一种基于任务预分配的任务申请装置和方法，将生成的任务放入任务池之前，先进行了预处理，将优先级比较高的高优先级任务放入高优先级队列中，将非高优先级任务放入能够申请该任务的录入用户的预分配任务队列中，并对高优先级队列和预分配任务队列内的任务进行优先级排序；当录入用户申请任务时，首先从高优先级队列中申请，申请不到再从预分配任务队列中申请，首先满足高优先级任务时效的需求，并且从该录入用户的预分配队列获取任务，无需和其他录入用户抢夺录入任务，不需要通过锁的方式去锁定资源，大大提升了录入的流畅性。

2、本发明一种基于任务预分配的任务申请装置和方法，通过任务类型、优先级、时效性以及入池顺序四个因素对任务的权重进行计算，保证需要优先处理的任务权重更高，能够优先被处理。

3、本发明一种基于任务预分配的任务申请装置和方法，根据录入用户的在线情况、录入用户具备的技能以及录入用户录入当前任务的犯错率选择出备选录入用户，再根据备选录入用户预分配任务队列的任务数量和最近完成任务的时间选择一最优的录入用户，保证任务能够快速的被录入用户接收并完成。

4、本发明一种基于任务预分配的任务申请装置和方法，高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建，大大降低系统IO资源，提升系统性能。

附图说明

图1为本发明实施例的流程图；

图2为本发明实施例中高优先级队列存储结构示例图；

图3为本发明实施例中录入用户的预分配任务队列的存储结构示例图；

图4为录入用户在客户端申请到任务的示例图。

具体实施方式

下面结合附图和具体实施例来对本发明进行详细的说明。

实施例一

一种的基于任务预分配的任务申请装置，包括存储器和处理器，所述存储器存储有指令，所述指令适于由处理器加载并执行以下步骤：

客户端接收任务的明细数据（明细数据是系统接收到票据后，通过OCR技术识别得到的电子数据）放入关系型数据库（关系型数据库是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。本实施例中采用Postgres数据库），并生成任务。

客户端判断生成的任务是否为高优先级任务，如演示任务、VIP客户的任务和核对任务，这些任务需要录入用户马上处理，马上返回的，对于时效性有很高的要求，这些任务会被判定为高优先级任务。

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户，参见图4，录入用户申请到任务后，在客户端展示出任务的明细数据。

本实施例的有益之处在于，在将生成的任务放入任务池之前，先进行了预处理，将优先级比较高的高优先级任务放入高优先级队列中，并对高优先级队列中的任务进行优先级排序，将非高优先级任务放入能够申请该任务的录入用户的预分配任务队列中，并在预分配任务队列内进行优先级排序；当录入用户申请任务时，首先从高优先级队列中申请，申请不到再从预分配任务队列中申请，首先满足高优先级任务时效的需求，并且从该录入用户的预分配队列获取任务，无需和其他录入用户抢夺录入任务，不需要通过锁的方式去锁定资源，大大提升了录入的流畅性。

实施例二

进一步的，所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比，上述远大于指的是后面的权重因素的权重占比影响不到前面的权重因素的权重占比；即这几个权重因素的权重占比排序为任务类型＞＞优先级＞＞时效性＞＞入池顺序；例如任务类型包括录入任务、核对任务和抽检任务，权重方面抽检＞核对＞录入；任务的排序首先考虑任务类型，即抽检类型的任务一定排在核对类型的任务之前；在任务类型相同的情况下，再考虑任务的优先级，任务的优先级按客户的重要性进行分级，越重点的客户的任务优先级越高，排序越靠前；如任务类型和优先级都相同，再考虑时效性，时效性要求越高的任务权重越大，排序越靠前；任务类型、优先级和时效性都相同的情况下，再考虑入池顺序，入池越久的任务权重越高，排序越靠前；参见图2和图3，例如，对不同任务类型的任务分别赋值成不同的六位数，如录入任务赋值170000，核对任务赋值为160000，抽检任务赋值150000；对不同优先级的任务分别赋值成不同的四位数，如按客户的重要性划分九个级别的优先级，第一级别赋值4849，第二级别赋值4848，第三级别赋值4847……第九级别赋值4841；对时效性不同要求的任务分别赋值成不同的十分位、百分位、千分位……；对不同时间入池的任务分别赋值成数值不同，且位于时效性数值位数之后的数字；通过以上方式，实现权重因素的权重占比排序任务类型＞＞优先级＞＞时效性＞＞入池顺序的目的。

进一步的，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户，排除的原因是为了提升录入的准确率，因为不同人犯同样错误的概率比同一个人犯同样错误的概率低；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

进一步的，所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。参见图2和图3，图2为高优先级队列的存储结构，任务号为键值，任务的权重用于排序，权重高的任务排在队列尾部，从高优先级队列申请任务时，从队列的尾部优先取，这样，权重高的高优先级任务就会先被申请到。图3为录入用户预分配任务队列的存储结构，队列名称带录入用户的用户号，任务号为键值，任务的权重用于排序，权重高的任务排在队列尾部，录入用户从预分配任务队列中申请任务的时候，从队列的尾部优先取，这样，权重高的队列就会先被申请到。

本实施例不仅具备实施例一的有益效果，进一步的，提出了通过任务类型、优先级、时效性以及入池顺序四个因素对任务的权重进行计算，保证需要优先处理的任务权重更高，能够优先被处理；提出选择录入用户的具体方式，首先根据录入用户的在线情况、录入用户具备的技能以及录入用户录入当前任务的犯错率选择出备选录入用户，再根据备选录入用户预分配任务队列的任务数量和最近完成任务的时间选择一最优的录入用户，保证任务能够快速的被录入用户接收并完成；高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建，大大降低系统IO资源，提升系统性能。

实施例三

一种基于任务预分配的任务申请方法，包括以下步骤：

客户端接收任务的明细数据（明细数据是系统接收到票据后，通过OCR技术识别得到的电子数据）放入关系型数据库（关系型数据库是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。本实施例中采用Postgres数据库），并生成任务。

客户端判断生成的任务是否为高优先级任务，如演示任务、VIP客户的任务和核对任务，这些任务需要录入用户马上处理，马上返回的，对于时效性有很高的要求，这些任务会被判定为高优先级任务。

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户，参见图4，录入用户申请到任务后，在客户端展示出任务的明细数据。

本实施例的有益之处在于，在将生成的任务放入任务池之前，先进行了预处理，将优先级比较高的高优先级任务放入高优先级队列中，并对高优先级队列中的任务进行优先级排序，将非高优先级任务放入能够申请该任务的录入用户的预分配任务队列中，并在预分配任务队列内进行优先级排序；当录入用户申请任务时，首先从高优先级队列中申请，申请不到再从预分配任务队列中申请，首先满足高优先级任务时效的需求，并且从该录入用户的预分配队列获取任务，无需和其他录入用户抢夺录入任务，不需要通过锁的方式去锁定资源，大大提升了录入的流畅性。

实施例四

进一步的，所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比，上述远大于指的是后面的权重因素的权重占比影响不到前面的权重因素的权重占比；即这几个权重因素的权重占比排序为任务类型＞＞优先级＞＞时效性＞＞入池顺序；例如任务类型包括录入任务、核对任务和抽检任务，权重方面抽检＞核对＞录入；任务的排序首先考虑任务类型，即抽检类型的任务一定排在核对类型的任务之前；在任务类型相同的情况下，再考虑任务的优先级，任务的优先级按客户的重要性进行分级，越重点的客户的任务优先级越高，排序越靠前；如任务类型和优先级都相同，再考虑时效性，时效性要求越高的任务权重越大，排序越靠前；任务类型、优先级和时效性都相同的情况下，再考虑入池顺序，入池越久的任务权重越高，排序越靠前；参见图2和图3，例如，对不同任务类型的任务分别赋值成不同的六位数，如录入任务赋值170000，核对任务赋值为160000，抽检任务赋值150000；对不同优先级的任务分别赋值成不同的四位数，如按客户的重要性划分九个级别的优先级，第一级别赋值4849，第二级别赋值4848，第三级别赋值 4847……第九级别赋值4841；对时效性不同要求的任务分别赋值成不同的十分位、百分位、千分位……；对不同时间入池的任务分别赋值成数值不同，且位于时效性数值位数之后的数字；通过以上方式，实现权重因素的权重占比排序任务类型＞＞优先级＞＞时效性＞＞入池顺序的目的。

进一步的，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户，排除的原因是为了提升录入的准确率，因为不同人犯同样错误的概率比同一个人犯同样错误的概率低；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

进一步的，所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。参见图2和图3，图2为高优先级队列的存储结构，任务号为键值，任务的权重用于排序，权重高的任务排在队列尾部，从高优先级队列申请任务时，从队列的尾部优先取，这样，权重高的高优先级任务就会先被申请到。图3为录入用户预分配任务队列的存储结构，队列名称带录入用户的用户号，任务号为键值，任务的权重用于排序，权重高的任务排在队列尾部，录入用户从预分配任务队列中申请任务的时候，从队列的尾部优先取，这样，权重高的队列就会先被申请到。

本实施例不仅具备实施例三的有益效果，进一步的，提出了通过任务类型、优先级、时效性以及入池顺序四个因素对任务的权重进行计算，保证需要优先处理的任务权重更高，能够优先被处理；提出选择录入用户的具体方式，首先根据录入用户的在线情况、录入用户具备的技能以及录入用户录入当前任务的犯错率选择出备选录入用户，再根据备选录入用户预分配任务队列的任务数量和最近完成任务的时间选择一最优的录入用户，保证任务能够快速的被录入用户接收并完成；高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建，大大降低系统IO资源，提升系统性能。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (8)

1.一种的基于任务预分配的任务申请装置，其特征在于，包括存储器和处理器，所述存储器存储有指令，所述指令适于由处理器加载并执行以下步骤：

客户端接收任务的明细数据并放入关系型数据库，并生成任务；

客户端判断生成的任务是否为高优先级任务；

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户。

2.根据权利要求1所述的一种基于任务预分配的任务申请装置，其特征在于：所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比。

3.根据权利要求1所述的一种基于任务预分配的任务申请装置，其特征在于，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

4.根据权利要求1所述的一种基于任务预分配的任务申请装置，其特征在于：所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。

5.一种基于任务预分配的任务申请方法，其特征在于，包括以下步骤：

客户端接收任务的明细数据并放入关系型数据库，并生成任务；

客户端判断生成的任务是否为高优先级任务；

如当前任务是高优先级任务，则将当前任务放入高优先级队列中，根据任务的权重因素对高优先级队列内的任务进行优先级排序；

如当前任务不是高优先级任务，则选择可执行当前任务的录入用户，将当前任务放入所述可执行当前任务的录入用户的预分配任务队列中，所述预分配任务队列根据任务的权重因素对预分配任务队列内的任务进行优先级排序；

录入用户向客户端发起申请任务请求；

如所述高优先级队列非空且存在当前录入用户有申请权限的任务，则当前录入用户立即申请到上述任务中优先级最高的任务；

如当前录入用户无法从高优先级队列内申请到任务，则从当前录入用户的预分配任务队列内分配出优先级最高的任务给当前录入用户；

录入用户获取任务后，客户端从关系型数据库中获取任务的明细数据返回给录入用户。

6.根据权利要求5所述的一种基于任务预分配的任务申请方法，其特征在于：所述任务的权重因素包括任务类型、优先级、时效性以及入池顺序；所述任务类型的权重占比远大于所述优先级的权重占比，所述优先级的权重占比远大于所述时效性的权重占比，所述时效性的权重占比远大于所述入池顺序的权重占比。

7.根据权利要求5所述的一种基于任务预分配的任务申请方法，其特征在于，所述选择可申请当前任务的录入用户的具体步骤如下：

计算出所有备选录入用户，所述备选录入用户需要满足以下要求：

录入用户为在线人员；

录入用户具备完成当前任务的技能；

如当前任务为多录任务或核对任务，需排除之前有录入过相同任务的录入用户；

从所有备选录入用户中选择一个可以申请当前任务的录入用户，首先选择预分配任务队列中任务数量最少的录入用户，如果预分配任务队列的任务数量相同，则选择最近一次提交任务时间近的录入用户。

8.根据权利要求5所述的一种基于任务预分配的任务申请方法，其特征在于：所述高优先级队列和所述预分配任务队列采用Redis的zset数据结构创建。