CN106470169A - 一种业务请求调整方法及设备 - Google Patents

Abstract

本申请公开了一种业务请求处理方法，在业务请求处理系统中预设第一队列以及第二队列，第一队列开启的线程的数量高于第二队列开启的线程的数量，且第一队列中的业务请求的优先级高于第二队列中的业务请求的优先级，在当到达调整时刻时判断第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值，若是则按照预设的调整策略将第二队列中的业务请求转移至第一队列中，从而能够根据资源的使用情况动态调整队列中业务请求所分配的资源，保障请求中优先级较高的业务请求能够及时被执行，以及在资源足够空闲时保障优先级较低的业务请求也能够尽快处理，提高了资源利用率。

Description

一种业务请求调整方法及设备

技术领域

本申请涉及通信技术领域，特别涉及一种业务请求调整方法。本申请同时还涉及一种业务请求处理设备。

背景技术

在目前的数据处理技术中，队列是一种特殊的线性表，特殊之处在于它只允许在表的前端(front)进行删除操作，而在表的后端(rear)进行插入操作，和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。队列中没有元素时，称为空队列。线程则为程序执行流的最小单元。

由于队列的特性是先入先出(先进入到队列当中的请求会优先被线程执行)，所以当系统中大量的请求进入到队列当中的话，不管请求作业的优先级高低，统统按照时间先后顺序进行排队获取资源。如果资源紧张时，高优先级作业进入队列时间靠后，便会在队列当中等待较长的时间，而有限的线程资源被低优先级的作业占用着，这样就无法保障业务上的优先级。

为解决该问题，现有技术中一般采取对不同的优先级的请求作业设置不同的队列的方式，同时为每个队列开启若干个线程，并尽量调大线程数以尽可能多的提供线程资源。

然而，发明人在实现本申请的过程中发现，对针对不同优先级的作业采用不同的队列以及为每个队列开启若干个线程时，如果某一种优先级的作业数量较少，那么这个队列当中的线程会大量被空闲。这种空闲就是对资源的浪费，这些线程本来是可以有效利用起来去执行其它请求的。而一味加大线程资源也不现实，毕竟服务器的性能终究是有瓶颈的。

发明内容

本申请提供了一种业务请求调整方法，用以有效的调节资源使用率，尽可能大的利用线程资源。该方法应用于包括第一队列以及第二队列的业务请求处理系统中，所述第一队列开启的线程的数量高于所述第二队列开启的线程的数量，所述第一队列中的业务请求的优先级高于所述第二队列中的业务请求的优先级，该方法包括：

当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值；

若所述数量小于所述处理阈值，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

优选的，还包括：

当接收到新的业务请求时，获取所述业务请求的优先级；

判断所述优先级是否高于预设的优先级阈值；

若所述优先级高于所述优先级阈值，将所述业务请求分发至所述第一队列；

若所述优先级低于所述优先级阈值，将所述业务请求分发至所述第二队列。

优选的，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于所述处理阈值，具体为：

判断所述第一队列中当前正在执行的作业线程的数量是否小于所述第一队列开启的线程的数量与线程保留数量之间的差值。

优选的，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中，具体为：

按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

优选的，在按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列之后，还包括：

重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。

相应地，本申请还提出了一种业务请求处理系统，该业务请求处理系统包括第一队列以及第二队列，所述第一队列开启的线程的数量高于所述第二队列开启的线程的数量，所述第一队列中的业务请求的优先级高于所述第二队列中的业务请求的优先级，该业务请求处理系统包括：

判断模块，当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值；

转移模块，用于在所述判断模块确认所述数量小于所述处理阈值时，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

优选地，还包括：

处理模块，当接收到新的业务请求时获取所述业务请求的优先级，并判断所述优先级是否高于预设的优先级阈值；

若所述优先级高于所述优先级阈值，所述处理模块将所述业务请求分发至所述第一队列；

若所述优先级低于所述优先级阈值，所述处理模块将所述业务请求分发至所述第二队列。

优选地，所述判断模块具体用于：

判断所述第一队列中当前正在执行的作业线程的数量是否小于所述第一队列开启的线程的数量与线程保留数量之间的差值。

优选地，所述转移模块具体用于：

按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

优选地，还包括：

计时模块，重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。

由此可见，通过应用本申请的技术方案，在业务请求处理系统中预设第一队列以及第二队列，第一队列开启的线程的数量高于第二队列开启的线程的数量，且第一队列中的业务请求的优先级高于第二队列中的业务请求的优先级，在当到达调整时刻时判断第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值，若是则按照预设的调整策略将第二队列中的业务请求转移至第一队列中，从而能够根据资源的使用情况动态调整队列中业务请求所分配的资源，保障请求中优先级较高的业务请求能够及时被执行，以及在资源足够空闲时保障优先级较低的业务请求也能够尽快处理，提高了资源利用率。

附图说明

图1为本申请提出的一种业务请求处理方法的流程示意图；

图2为本申请具体实施例中业务请求处理的具体方案示意图；

图3为本申请提出的一种业务请求处理设备的结构示意图。

具体实施方式

有鉴于背景技术中的问题，本申请提出了一种业务请求处理方法，主要解决在线程资源紧张的情况下保障队列中优先级高的作业得到第一时间的执行，以及在线程资源空闲的时候保障低优先级的作业也能够得到有效的执行。

为了实现以上目的，此本申请在一个业务请求处理系统分别设置了第一队列以及第二队列，其中第一队列开启的线程的数量高于第二队列开启的线程的数量，出于资源利用的角度，第一队列开启的线程的数量可以远高于第二队列开启的线程的数量，而第二队列开启的线程的数量甚至可以设置为0。同时技术人员也可以针对业务请求的不同优先级设置优先级阈值，保证第一队列中的业务请求的优先级高于第二队列中的业务请求的优先级，从而使得第二队列作为相对于第一队列的辅助队列。在后续的过程中，主要由第一队列利用大部分处理资源处理重要的业务请求，第二队列则用来存储当前并不紧急的业务请求，所分配的处理资源相对于第一队列也少得多(甚至没有)。

如图1所示，该方法包括以下步骤：

S101，当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值。

在本申请的优选实施例中，该步骤中利用当前作业的线程数量对于正在处理的业务请求数量进行判断，具体的，可预先设置一个线程保留数量，该数量指示了第一队列所开启的队列中所需要保留出来处理即将到来业务请求的线程数量，在需要进行判断处理的时候，通过第一队列中当前正在执行的作业线程的数量是否小于第一队列开启的线程的数量与线程保留数量之间的差值来确认第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值。

为了保证高优先级的业务请求都存储在第一队列中，在本申请的优选实施例中，当接收到新的业务请求时，首先是获取该业务请求的优先级，随后判断优先级是否高于预设的优先级阈值，如果优先级高于所述优先级阈值，则将业务请求分发至所述第一队列，而若所述优先级低于优先级阈值，则将业务请求分发至所述第二队列。

S102，若所述数量小于所述处理阈值，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

由于每次转移的数量有限，为能够当前有需要的业务请求转移至第一队列，本申请提出了一下三种不同的方案：

(1)按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中。

在该方案中，直接按照当前最大的能转移的数量将业务请求从第二队列转移至第一队列，其中能够转移的业务请求的选择可由技术人员指定，也可由系统随机进行选择，这些都不影响本申请的保护范围。

(2)根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中。

在该方案中，技术人员通过预设一个对应关系，包含了第一队列的空闲程度与可转移的业务请求的数量的关系，换言之，如果第一队列当前越是空闲，那么可转移的业务请求的数量就更多。

(3)确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

在该方案中，通过一个预设的公式，结合每个业务请求进入第二队列的时间长短以及优先级计算各个业务请求的综合权重值，随后按照可转移的最大数量选择综合权重值最高的若干业务请求从第二队列转移至第一队列。

需要说明的是，以上转移方案以及策略中需要转移的业务请求的确定方式均为本申请提出的优选实施方案，在此基础上的其他改进均属于本申请的保护范围。

为实现第一队列以及第二队列中业务请求的动态调整，本申请每隔一段时间即执行一次以上步骤，因此在该步骤之后可重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。

为了进一步阐述本申请的技术思想，现结合如图2所示的具体方案示意图，对本申请的技术方案进行说明。在该方案示意图中，预先设置了StrongQueue(强队列)以及Weak Queue(弱队列)两个队列，Request(请求)通过Dispatcher(分配器)被分配至相应的队列。具体流程如下：

步骤a)请求Request通过请求分发器Dispatcher进入到不同的队列当中。举例来说，若请求优先级为0～10(从高到低)，那么可以设置当请求优先级>5时候分发到缓冲队列Weak Queue中，反之就进入Strong Queue。

其中，该具体实施例中为StrongQueue开启了M个线程，而Weak Queue是缓冲队列，并没有开启线程服务。

步骤b)线程pick up执行进入到Strong Queue的业务请求。

步骤c)在到达调整时刻时进行业务请求的转移。

假设当前正在执行的作业线程为R个(R<＝M)，那么当R<M-N时(N可以根据自己的业务设定)，调整缓冲队列Weak Queue当中的作业请求若干个进入到Strong Queue。该方法每隔若干时间轮询一次(比如DQC是每隔10s挪动10个请求作业)。

举例来说，当Strong Queue开启了80个线程(M)，N为30。那么当前正在被线程处理的请求数<50时，每隔10s挪动10个请求进入Strong Queue执行。这样，就保障了在业务高峰期优先级高的作业直接进入Strong Queue执行，而优先级低的作业在资源空闲时可根据业务调整进入Strong Queue执行。并且这种设计还能够保障N-10个线程始终为进入到Strong Queue的请求服务，防止短时间内大量优先级低的作业调整进入到Strong Queue，而优先级高的作业进入时无线程资源的情况出现。

此外，该步骤中可以通过算法将请求从Weak Queue挪动到Strong Queue，是有个算法的。例如请求的优先级是P，那么会根据：0.7*10*P+0.3*进入队列的时间的结果排序，选取最小的10个请求进行调整。这个是因为优先级粒度是不同的，并且要综合考虑请求发送的时间，选取最紧急和优先级稍高的任务进入Strong Queue执行，其中算法的权重值可以根据实际业务调节。

在以上的业务请求调整方法中，通过设置缓冲队列，根据资源的使用情况动态调整队列中的请求获取资源。从而能够保障请求中优先级较高的作业能够及时被执行，同时在资源足够空闲时，优先级较低的作业也能够尽快被有效执行。

为达到以上技术目的，本申请还提出了一种业务请求处理系统，所述业务请求处理系统包括第一队列以及第二队列，所述第一队列开启的线程的数量高于所述第二队列开启的线程的数量，所述第一队列中的业务请求的优先级高于所述第二队列中的业务请求的优先级，如图3所示，该业务请求处理系统包括：

判断模块310，当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值；

转移模块320，用于在所述判断模块确认所述数量小于所述处理阈值时，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

在具体的应用场景中，还包括：

处理模块，当接收到新的业务请求时获取所述业务请求的优先级，并判断所述优先级是否高于预设的优先级阈值；

若所述优先级高于所述优先级阈值，所述处理模块将所述业务请求分发至所述第一队列；

若所述优先级低于所述优先级阈值，所述处理模块将所述业务请求分发至所述第二队列。

在具体的应用场景中，所述判断模块具体用于：

判断所述第一队列中当前正在执行的作业线程的数量是否小于所述第一队列开启的线程的数量与线程保留数量之间的差值。

在具体的应用场景中，所述转移模块具体用于：

按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

在具体的应用场景中，其特征在于，还包括：

计时模块，重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种业务请求调整方法，其特征在于，所述方法应用于包括第一队列以及第二队列的业务请求处理系统中，所述第一队列开启的线程的数量高于所述第二队列开启的线程的数量，所述第一队列中的业务请求的优先级高于所述第二队列中的业务请求的优先级，该方法包括：

当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值；

若所述数量小于所述处理阈值，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

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

当接收到新的业务请求时，获取所述业务请求的优先级；

判断所述优先级是否高于预设的优先级阈值；

若所述优先级高于所述优先级阈值，将所述业务请求分发至所述第一队列；

若所述优先级低于所述优先级阈值，将所述业务请求分发至所述第二队列。

3.如权利要求1所述的方法，其特征在于，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于所述处理阈值，具体为：

判断所述第一队列中当前正在执行的作业线程的数量是否小于所述第一队列开启的线程的数量与线程保留数量之间的差值。

4.如权利要求1所述的方法，其特征在于，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中，具体为：

按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

5.如权利要求1所述的方法，其特征在于，在按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列之后，还包括：

重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。

6.一种业务请求处理系统，其特征在于，所述业务请求处理系统包括第一队列以及第二队列，所述第一队列开启的线程的数量高于所述第二队列开启的线程的数量，所述第一队列中的业务请求的优先级高于所述第二队列中的业务请求的优先级，该业务请求处理系统包括：

判断模块，当到达调整时刻时，判断所述第一队列中当前正在被线程处理的业务请求的数量是否小于处理阈值；

转移模块，用于在所述判断模块确认所述数量小于所述处理阈值时，按照预设的调整策略将所述第二队列中的业务请求转移至所述第一队列中。

7.如权利要求6所述的业务请求处理系统，其特征在于，还包括：

处理模块，当接收到新的业务请求时获取所述业务请求的优先级，并判断所述优先级是否高于预设的优先级阈值；

若所述优先级高于所述优先级阈值，所述处理模块将所述业务请求分发至所述第一队列；

若所述优先级低于所述优先级阈值，所述处理模块将所述业务请求分发至所述第二队列。

8.如权利要求6所述的业务请求处理系统，其特征在于，所述判断模块具体用于：

判断所述第一队列中当前正在执行的作业线程的数量是否小于所述第一队列开启的线程的数量与线程保留数量之间的差值。

9.如权利要求6所述的业务请求处理系统，其特征在于，所述转移模块具体用于：

按照预设的转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，根据转移数量与所述第一队列中当前空闲的线程之间的对应关系确定转移数量，并按照所述转移数量的将业务请求从所述第二队列转移至所述第一队列中；

或，确定所述第二队列中各业务请求的综合权重，按照预设的转移数量以及综合权重由高至低的顺序将所述第二队列中的业务请求转移至所述第一队列中。

10.如权利要求6所述的业务请求处理系统，其特征在于，还包括：

计时模块，重新进行计时，并按照预设的时间阈值判断当前是否到达调整时刻。