CN106775990A

CN106775990A - 请求调度方法和装置

Info

Publication number: CN106775990A
Application number: CN201611268231.6A
Authority: CN
Inventors: 杨谦; 胡炜; 王鑫
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Group Jiangsu Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Group Jiangsu Co Ltd
Priority date: 2016-12-31
Filing date: 2016-12-31
Publication date: 2017-05-31

Abstract

本申请涉及请求调度方法和装置。本申请提供了一种请求调度方法，包括：基于接入优先级向请求分配请求线程；将请求发送到请求队列；以及基于处理优先级从请求队列中选择要处理的请求。本申请还提供了一种请求调度装置，包括：处理器；以及存储器，用于存储指令，当指令被执行时使得处理器执行下述操作：基于接入优先级向请求分配请求线程；将请求发送到请求队列；以及基于处理优先级从请求队列中选择要处理的请求。根据本申请实施例的请求调度方法和装置能够保证高并发访问时系统的稳定性，实现资源的动态调配，提高资源利用率。

Description

请求调度方法和装置

技术领域

本申请总体涉及移动网络通信领域，更具体地，涉及请求调度方法和装置。

背景技术

目前的业务支撑系统(包括客户关系管理系统(CRM)、业务运营支撑系统(BOSS)、经营分析系统(BAS)、业务支撑网运营管理系统(BOMC)等)大多采用模型-视图-控制器(MVC)架构，并采用NIO线程池接收处理请求，遵循先到先分配资源及先到先处理的原则，不考虑后端的处理能力，系统呈现无限接入及有限处理的现状。同时，对所有请求采取公平公正的处理方式，均等分配资源。当系统性能需要扩展时，需要人工完成机器申请、采购、安装、开通网络策略等流程。

发明内容

本申请的实施例提供了一种请求调度方法和装置，能够提高高并发系统的稳定性，动态调配资源，提高资源利用率。

第一方面，提供了一种请求调度方法，包括：基于接入优先级向请求分配请求线程；将请求发送到请求队列；以及基于处理优先级从请求队列中选择要处理的请求。

第二方面，提供了一种请求调度装置，包括：处理器；以及存储器，用于存储指令，当指令被执行时使得处理器执行下述操作：基于接入优先级向请求分配请求线程；将请求发送到请求队列；以及基于处理优先级从请求队列中选择要处理的请求。

在根据本申请实施例的请求调度方法和装置中，由于对业务服务的请求进行分段处理，将请求阶段和处理阶段分成独立的过程，并结合队列缓冲，将接入请求堆积在中间层的请求队列中，因此后端能够根据处理能力及请求处理优先级进行处理，从而能够保证高并发访问时系统的稳定性。同时，结合弹性调度平台，实现对用于处理请求的资源的扩缩容和动态调配，提高资源利用率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本申请实施例的基于阶段性事件驱动架构(SEDA)和Docker的系统架构的示意性框图。

图2示出了根据本申请实施例的请求调度方法的示意性流程图。

图3示出了根据本申请实施例的请求调度装置的示意性框图。

图4示出了能够实现根据本申请实施例的请求调度方法的至少一部分的计算设备的示例性硬件架构的结构图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部实施例。基于本申请的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面将详细描述本申请的各个方面的特征和示例性实施例。在下面的详细描述中，提出了许多具体细节，以便提供对本申请的全面理解。但是，对于本领域技术人员来说很明显的是，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请的更好的理解。本申请不限于下面所提出的任何具体配置和算法，而是在不脱离本申请的精神的前提下覆盖了元素、部件和算法的任何修改、替换和改进。在附图和下面的描述中，没有示出公知的结构和技术，以便避免对本申请造成不必要的模糊。

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本申请更全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。在图中，为了清晰，可能夸大了区域和层的厚度。在图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有所述特定细节中的一个或更多，或者可以采用其它的方法、组元、材料等。在其它情况下，不详细示出或描述公知结构、材料或者操作以避免模糊本申请的主要技术创意。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

现有业务支撑系统数据处理存在的问题有：1)传统IT系统脆弱，无法抵挡爆发式访问冲击。传统的IT系统受限于后端数据库以及业务复杂度，业务系统通常都是接入能力强，处理能力弱。当系统接入的并发请求过多时，导致整个系统运行缓慢，夯死甚至存在系统崩溃的风险，进而导致业务无法办理，严重影响用户体验；2)应用服务无法按优先级分配资源，无法保障重点业务的处理时效性。传统的IT系统针对不同的业务(如对时效性要求高、且频繁需要处理的重点业务，对时效性要求不高、使用较少的边缘业务)，遵循先到先得原则均等分配资源，当系统资源紧张时，无法优先保证重点业务的资源分配及处理时效性；3)系统忙闲资源分配不均，资源利用率较低。传统的IT系统以一个周期内的使用峰值为标准，为应用配置资源，不支持智能伸缩。资源的使用率一般在10％-20％之间，闲时业务访问量较低、资源闲置，忙时业务访问量成倍增长，无法有效利用其它系统的闲置资源。

考虑到上述情况，本申请提供了一种请求调度方法和装置，利用SEDA对业务服务的请求进行分段处理，将请求阶段和处理阶段分成独立的过程，并结合队列缓冲，将接入请求堆积在中间层的请求队列中，因此后端能够根据处理能力及请求处理优先级进行处理，从而能够保证高并发访问时系统的稳定性。同时，结合基于Docker的弹性调度平台进行资源的智能管理与调度，实现资源的动态调配，提高资源利用率。

图1示出了根据本申请实施例的基于SEDA和Docker的系统架构的示意性框图。基于SEDA和Docker的系统架构可以主要包括同步请求异步化、基于服务治理的服务优先级调度、资源调度算法三个功能模块。

在同步请求异步化模块中，可以利用SEDA对业务服务的请求进行分段处理，并结合队列缓冲，实现请求和处理解耦，解决高并发系统稳定性差的问题。同时，可以在SEDA分阶段的基础上实现对队列层的控制，即采用线程和队列的方式，以异步请求模拟同步请求，在不影响响应实时性的前提下提高处理效率及资源利用率。在一些实施例中，同步请求异步化的实现过程例如可以为：1)服务接入单元中的请求接收线程组可以基于服务请求的接入优先级接收服务请求，该请求接收线程组可以调用基于服务治理的服务优先级调度模块中的优先策略，根据服务请求的接入优先级分配不同的线程组资源，以保障高接入优先级的服务请求获得较多的线程资源；2)可以将接收到的服务请求经由分发线程批量发送给服务队列单元中的请求队列组，并挂起服务请求线程，等待哨兵线程返回结果后可以唤醒该服务请求线程，以避免该服务请求线程占用资源；3)服务消费单元中的请求处理线程组可以同样调用基于服务治理的服务优先级调度模块对服务请求进行处理。该请求处理线程组可以基于请求的处理优先级并且根据后端服务的处理能力，采用拉的模式从请求队列组拉取待处理的服务请求并进行处理，非待处理的服务请求可以堆积在请求队列组中，以避免压垮后端服务；4)服务消费单元中的请求处理线程组可以在处理完服务请求后，将处理结果发送给结果队列组，同时可以拉取新的服务请求进行处理；5)当哨兵线程监听到结果队列组中存在相关处理结果后，可以唤醒挂起的服务请求线程；6)哨兵线程可以将处理结果发送给请求接收线程组。

在基于服务治理的服务优先级调度模块中，可以支持业务服务优先级的在线动态调整及升降级处理，以保障业务高峰期时高优先级服务资源的投入。在一些实施例中，基于服务治理的服务优先级调度模块可以分为服务接入优先级管理单元、服务治理规则库和服务处理优先级管理单元。服务接入优先级管理单元的原理例如可以为：在服务接入端，基于服务治理规则库中预定义的业务服务的优先级属性，根据优先级别分配相应的接入线程数。在一些实施例中，请求接收线程组在接收到例如告警查询服务请求、日志查询服务请求后，可以基于服务治理规则库中预配置的告警查询、日志查询服务的接入优先级属性来确定相应的专用接入线程组。例如，告警查询服务可以为高优先级，则可以将其适配到高优先级线程组处理，日志查询服务可以为低优先级，则可以将日志查询服务适配到低优先级的线程组处理。在一些实施例中，当监测到业务服务的接入量满足一定条件时，可以动态调整优先级别，并可以同时相应调整其处理线程数。下面表1举例示出了为服务甲和服务乙分配的接入优先级别和接入线程数、以及处理优先级别和处理线程数。业务服务处理优先级管理单元的原理及调整方式与服务接入优先级管理单元类似，在此不再赘述。

表1

服务名称	接入优先级别	接入线程数	处理优先级别	处理线程数
					甲	1	100	1	100
乙	3	300	4	400

在本申请中，可以将系统部署到例如Docker上，利用容器快速部署及强大的资源调度计算能力，按照业务量的需求对应用进行实时地秒级扩缩容。同时，在应用内部，可以通过判断请求处理线程组的使用率，根据线程处理的忙闲进行线程的扩缩容，通过这两级的调度实现资源的高效利用及处理效率的快速提升。

在资源调度算法模块中，在一些实施例中，可以采用加权资源调度算法，通过监控容器及容器内资源，将容器或线程的主导资源需求(即分配给该容器或线程的资源中份额最大的资源)作为参考，同时根据业务服务的优先级权重，实现资源的分配与调度。可以利用设定的限制条件及策略确定各资源的分配并进行动态调整，即可以在资源总量范围内，计算出最大化利用资源A和B的最优分配。例如，加权资源调度算法可以如下述公式(1)-(3)所示：

其中，T_资源A表示资源A的总量，T_资源B表示资源B的总量，β表示根据服务甲的优先级确定的权重，γ表示根据服务乙的优先级确定的权重，f(a₁,x)*β表示服务甲用到的资源A的总量，f(a₂,y)*γ表示服务乙用到的资源A的总量，f(b₁,x)*β表示服务甲用到的资源B的总量，f(b₂,y)*γ表示服务乙用到的资源B的总量，max(a₁,b₁)*β表示服务甲的主导资源需求，max(a₂,b₂)*γ表示服务乙的主导资源需求。公式(1)可以表示服务甲用到的资源A总数与服务乙用的资源A总数之和不能大于资源A总数；公式(2)可以表示服务甲用到的资源B总数与服务乙用的资源B总数之和不能大于资源B总数；公式(3)可以表示服务甲和服务乙的主导资源使用率相等。根据上述公式(1)-(3)可以计算出x和y，即可以确定资源利用率最大化时资源A和B的最优分配，从而根据优先级权重实现资源利用率的最大化。

在一些实施例中，可以在接入服务请求之前首先启动应用集群。在一些实施例中，可以启动部署在Docker中的接入集群、队列集群、消费集群，通过监控Docker容器内已分配的请求线程及处理线程的资源使用情况，实现对容器及容器内线程的弹性资源调度。在一些实施例中，可以在对服务请求的处理完成并返回处理结果后，触发调度平台对各Docker集群进行监控。调度平台可以对Docker容器的资源使用率进行监控统计，如CPU、内存、网络I/O等资源的使用情况、容器内线程使用率、容器内队列内存占用率等，并将这些资源使用率情况发送至缓存进行存储。在一些实施例中，可以根据监测到的资源使用率、线程资源阀值执行线程扩缩容，并可以依据资源调度算法进行线程资源的最优分配。例如，当请求、处理线程利用率大于最高阀值时，可以增加线程池中的线程数，直至线程利用率达到标准阀值；当线程利用率小于最低阀值时，可以减少线程池中的线程数，直至线程利用率达到标准阀值。在完成线程扩缩容后，还可以依据资源调度算法(例如，上述公式(1)-(3)所述的加权资源调度算法)进行线程资源的最优分配。类似地，在一些实施例中，可以根据容器资源阀值执行容器扩缩容，并可以依据资源调度算法进行容器资源的最优分配。例如，可以根据缓存中的资源使用率确定当前的容器资源使用率，若容器资源使用率大于最高阀值，则可以将Docker容器扩容，直至资源使用率达到标准阀值，反之，可以将Docker容器缩容，直至资源使用率达到标准阀值。在一些实施例中，容器资源使用率例如可以表示为R＝X*a+Y*b(a+b＝1)，X、Y例如可以为CPU使用率、内存使用率；a、b例如可以分别为X、Y的权重。完成扩缩容后，还可以依据资源调度算法(例如，上述公式(1)-(3)所述的加权资源调度算法)进行容器资源的最优分配。

图2示出了根据本申请实施例的请求调度方法的示意性流程图。如图2所示，根据本申请实施例的请求调度方法200可以包括：S202，基于接入优先级向请求分配请求线程；S204，将请求发送到请求队列；以及S206，基于处理优先级从请求队列中选择要处理的请求。

在一些实施例中，在S202中，如图1中所示的请求接收线程组在接收请求时，可以基于请求的接入优先级向请求分配相应的请求线程。在一些实施例中，请求接收线程组可以从例如图1中所示的基于服务治理的服务优先级调度模块中的服务接入优先级管理单元获取请求的接入优先级，并且可以根据所获取的请求的接入优先级向请求分配相应的请求线程。例如，如上述图1中所述，可以向高优先级服务请求分配高优先级线程组，向低优先级服务请求分配低优先级线程组。

在一些实施例中，在S204中，可以经由如图1中所示的分发线程将请求发送到请求队列。在一些实施例中，可以分别将不同优先级线程组中的请求转换成标准的消息格式，按照分组信息和消息负载组成消息体，批量分发给相应的请求队列，请求队列可以根据请求接入优先级属性及自身队列的处理能力进行消息的接收、过滤、存储等操作。

在一些实施例中，在S206中，如图1中所示的请求处理线程组可以基于处理优先级从请求队列中选择要处理的请求。在一些实施例中，请求处理线程组可以从例如图1中所示的基于服务治理的服务优先级调度模块中的服务处理优先级管理单元获取请求的处理优先级，并且可以根据所获取的请求的处理优先级从请求队列中选择要处理的请求。

在一些实施例中，请求调度方法200还可以包括：利用处理线程对所选择的请求进行处理。在一些实施例中，请求处理线程组可以对从请求队列中选择的请求进行处理。在一些实施例中，用于处理所选择的请求的处理线程可以基于资源调度算法来分配。例如，可以基于如图1中所详述的加权资源调度算法来对处理线程进行最优分配，以提高资源利用率，在此不再赘述。

在一些实施例中，请求调度方法200还可以包括：在将请求发送到请求队列之后，挂起请求线程；以及在对所选择的请求的处理完成之后，唤醒向所选择的请求分配的请求线程。在一些实施例中，请求调度方法200还可以包括：在将请求发送到请求队列之后，挂起请求线程；在对所选择的请求的处理完成之后，将处理结果发送到结果队列；以及唤醒向与结果队列中的每个结果相对应的请求分配的请求线程。在一些实施例中，例如可以在将请求发送到请求队列后挂起请求线程，并触发如图1中所示的哨兵线程监听结果队列中的处理结果。在一些实施例中，当哨兵线程监听到结果队列中针对请求的处理结果后，则可以唤醒请求队列中挂起的请求线程。

在一些实施例中，请求调度方法200还可以包括：监测线程使用率；以及基于所监测的线程使用率来调整线程池容量。在一些实施例中，调整线程池容量可以包括：当线程使用率高于第一预定阈值时，增大线程池容量；以及当线程使用率低于第二预定阈值时，缩小线程池容量，其中，第二预定阈值低于第一预定阈值。在一些实施例中，线程可以是请求线程和/或处理线程。例如，当请求、处理线程利用率大于最高阀值时，可以增加线程池中的线程数，直至线程利用率达到标准阀值；当线程利用率小于最低阀值时，可以减少线程池中的线程数，直至线程利用率达到标准阀值。在完成线程扩缩容后，还可以依据资源调度算法(例如，上述公式(1)-(3)所述的加权资源调度算法)进行线程资源的最优分配。

图3示出了根据本申请实施例的请求调度装置的示意性框图。如图3所示，根据本申请实施例的请求调度装置300可以包括：处理器402；以及存储器404，用于存储指令，当指令被执行时使得处理器执行下述操作：基于接入优先级向请求分配请求线程；将请求发送到请求队列；以及基于处理优先级从请求队列中选择要处理的请求。

在一些实施例中，处理器可以包括但不限于通用处理器、专用处理器、微处理器等。在一些实施例中，存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现。存储器可以包括半导体存储器，例如随机存储器(RAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、只读存储器(ROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、快闪存储器等。存储器也可以包括例如使用纸介质、磁介质和/或光介质的任何存储器，如纸带、硬盘、磁带、软盘、磁光盘(MO)、CD、DVD、Blue-ray等。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：在接收请求时，可以基于请求的接入优先级向请求分配相应的请求线程。在一些实施例中，指令被执行时还可以使处理器执行下述操作：可以从例如图1中所示的基于服务治理的服务优先级调度模块中的服务接入优先级管理单元获取请求的接入优先级，并且可以根据所获取的请求的接入优先级向请求分配相应的请求线程。例如，如上述图1中所述，可以向高优先级服务请求分配高优先级线程组，向低优先级服务请求分配低优先级线程组。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：可以经由如图1中所示的分发线程将请求发送到请求队列。在一些实施例中，可以分别将不同优先级线程组中的请求转换成标准的消息格式，按照分组信息和消息负载组成消息体，批量分发给相应的请求队列，请求队列可以根据请求接入优先级属性及自身队列的处理能力进行消息的接收、过滤、存储等操作。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：可以从例如图1中所示的基于服务治理的服务优先级调度模块中的服务处理优先级管理单元获取请求的处理优先级，并且可以根据所获取的请求的处理优先级从请求队列中选择要处理的请求。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：利用处理线程对所选择的请求进行处理。在一些实施例中，用于处理所选择的请求的处理线程可以基于资源调度算法来分配。例如，可以基于如图1中所详述的加权资源调度算法来对处理线程进行最优分配，以提高资源利用率，在此不再赘述。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：在将请求发送到请求队列之后，挂起请求线程；以及在对所选择的请求的处理完成之后，唤醒向所选择的请求分配的请求线程。在一些实施例中，指令被执行时还可以使处理器执行下述操作：在将请求发送到请求队列之后，挂起请求线程；在对所选择的请求的处理完成之后，将处理结果发送到结果队列；以及唤醒向与结果队列中的每个结果相对应的请求分配的请求线程。在一些实施例中，指令被执行时还可以使处理器执行下述操作：例如可以在将请求发送到请求队列后挂起请求线程，并触发如图1中所示的哨兵线程监听结果队列中的处理结果。在一些实施例中，指令被执行时还可以使处理器执行下述操作：当哨兵线程监听到结果队列中针对请求的处理结果后，则可以唤醒请求队列中挂起的请求线程。

在一些实施例中，指令被执行时还可以使处理器执行下述操作：监测线程使用率；以及基于所监测的线程使用率来调整线程池容量。在一些实施例中，调整线程池容量可以包括：当线程使用率高于第一预定阈值时，增大线程池容量；以及当线程使用率低于第二预定阈值时，缩小线程池容量，其中，第二预定阈值低于第一预定阈值。在一些实施例中，线程可以是请求线程和/或处理线程。例如，当请求、处理线程利用率大于最高阀值时，可以增加线程池中的线程数，直至线程利用率达到标准阀值；当线程利用率小于最低阀值时，可以减少线程池中的线程数，直至线程利用率达到标准阀值。在完成线程扩缩容后，还可以依据资源调度算法(例如，上述公式(1)-(3)所述的加权资源调度算法)进行线程资源的最优分配。

结合图2描述的请求调度方法200的至少一部分可以由计算设备实现。图4示出了能够实现根据本申请实施例的请求调度方法200的至少一部分的计算设备的示例性硬件架构的结构图。如图4所示，计算设备400包括输入设备401、输入接口402、中央处理器403、存储器404、输出接口405、以及输出设备406。其中，输入接口402、中央处理器403、存储器404、以及输出接口405通过总线410相互连接，输入设备401和输出设备406分别通过输入接口402和输出接口405与总线410连接，进而与计算设备400的其他组件连接。具体地，输入设备401接收来自外部的输入信息，并通过输入接口402将输入信息传送到中央处理器403；中央处理器403基于存储器404中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器404中，然后通过输出接口405将输出信息传送到输出设备406；输出设备406将输出信息输出到计算设备600的外部。

需要明确，本申请并不局限于上文所描述并在图中示出的特定配置和处理。并且，为了简明起见，这里省略对已知方法技术的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后作出各种改变、修改和添加，或者改变步骤之间的顺序。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的组件及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现。所描述的功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims

1.一种请求调度方法，包括：

基于接入优先级向请求分配请求线程；

将所述请求发送到请求队列；以及

基于处理优先级从所述请求队列中选择要处理的请求。

2.如权利要求1所述的方法，还包括：

利用处理线程对所选择的请求进行处理。

3.如权利要求2所述的方法，还包括：

在将所述请求发送到所述请求队列之后，挂起所述请求线程；以及

在对所选择的请求的处理完成之后，唤醒向所选择的请求分配的请求线程。

4.如权利要求2所述的方法，还包括：

在将所述请求发送到所述请求队列之后，挂起所述请求线程；

在对所选择的请求的处理完成之后，将处理结果发送到结果队列；以及

唤醒向与所述结果队列中的每个结果相对应的请求分配的请求线程。

5.根据权利要求1所述的方法，还包括：

监测线程使用率；以及

基于所监测的线程使用率来调整线程池容量。

6.根据权利要求5所述的方法，其中，调整线程池容量包括：

当线程使用率高于第一预定阈值时，增大线程池容量直到线程使用率达到预定标准阈值；以及

当线程使用率低于第二预定阈值时，缩小线程池容量直到线程使用率达到所述预定标准阈值，

其中，所述第二预定阈值低于所述第一预定阈值。

7.根据权利要求5所述的方法，其中，所述线程是请求线程和/或处理线程。

8.根据权利要求2所述的方法，其中，所述处理线程是基于以下各项中的至少一项来分配的：所述请求的处理优先级、所述处理线程的总量、以及用于处理线程分配的预定限制条件。

9.一种请求调度装置，包括：

处理器；以及

存储器，用于存储指令，当所述指令被执行时使得所述处理器执行下述操作：

基于接入优先级向请求分配请求线程；

将所述请求发送到请求队列；以及

基于处理优先级从所述请求队列中选择要处理的请求。

10.如权利要求9所述的装置，其中，所述指令被执行时还使得所述处理器执行下述操作：

利用处理线程对所选择的请求进行处理。

11.如权利要求10所述的装置，其中，所述指令被执行时还使得所述处理器执行下述操作：

12.如权利要求10所述的装置，其中，所述指令被执行时还使得所述处理器执行下述操作：

13.根据权利要求9所述的装置，其中，所述指令被执行时还使得所述处理器执行下述操作：

监测线程使用率；以及

基于所监测的线程使用率来调整线程池容量。

14.根据权利要求13所述的装置，其中，调整线程池容量包括：

其中，所述第二预定阈值低于所述第一预定阈值。

15.根据权利要求13所述的装置，其中，所述线程是请求线程和/或处理线程。

16.根据权利要求10所述的装置，其中，所述处理线程是基于以下各项中的至少一项来分配的：所述请求的处理优先级、所述处理线程的总量、以及用于处理线程分配的预定限制条件。