消息调度控制方法及其相应的装置、设备、介质与流程

1.本技术实施例涉及互联网任务调度技术，尤其涉及一种消息调度控制方法及其相应的装置、设备、介质。


背景技术：

2.互联网应用中经常使用消息队列作为中间件，一般用来实现服务解耦，流量削峰和异步化处理等功能。但是实际应用中，当生产大量时消费端经常遇到两方面的问题：一是消费太快，导致的结果是给下游服务造成巨大请求的压力，甚至压垮下游服务。下游服务也包括系统内部使用的数据库、文件系统等等。二是消费太慢，消息出现严重堆积，消息得不到及时消费，对业务的实时性造成影响。
3.当前的业界主要的消息中间件，其消费端的配置参数都是静态配置的，消费者启动后不能进行动态变更，更无法随着消息量变化按照系统管理者的意图实现动态控制。因此，目前常见的消息队列的消费端没有动态控制消息消费速度的技术，以至于当出现消息堆积时，只能修改配置参数重启服务，或者通过节点扩缩容方式去解决消费太快或太慢的问题，这将导致部署成本的增加。
4.因此，根据本技术人的理解，针对消息队列的任务调度机制，影响到互联网后台的响应效率及部署成本，理想的状态是实现消息队列根据下游服务的负载情况进行均衡调度，期望可以由此实现消费的动态控制，尽可能快速便捷地解决消费太快或者消费太慢带来的系统问题。


技术实现要素：

5.本技术的目的是针对现有技术中存在的至少部分不足或为满足现有技术的至少部分需求而提供一种消息调度控制方法及其相应的装置、计算机设备及存储介质。
6.为解决上述技术问题，本技术采用的一个技术方案是：
7.本技术提供一种消息调度控制方法，包括如下步骤：
8.持续获取每秒请求总量及其每请求的平均执行时长，所述每秒请求总量通过持续统计从消息队列调度给下游服务的消息线程的总量而获得，所述平均执行时长为根据每秒请求总量计算出的每请求的平均值；
9.监听每秒请求总量的变动，当每秒请求总量超过所述下游服务的每秒请求阈值时，控制当前消息线程处于延缓执行的缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短；
10.统计当前消息线程相对应的前方阻塞量，根据前方阻塞量与所述平均执行时长的乘积计算当前消息线程对应的预期排队时长；
11.监听预期排队时长的变动，当当前消息线程的预期排队时长超过预设延迟阈值时，控制当前消息线程处于等待同步执行的活跃状态，将其释放时长归零，且，在当前消息线程连续多次处于活跃状态时，将当前消息线程交付异步执行。
12.较佳的实施例中，所述消息队列中的每个所述的消息线程均作为所述的当前消息线程独立执行本方法的各个步骤。
13.具体化的实施例中，监听每秒请求总量的变动，当每秒请求总量超过所述下游服务的每秒请求阈值时，控制当前消息线程处于延缓执行的缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短，包括如下步骤：
14.监听获取每次统计产生的每秒请求总量，比较每秒请求总量与所述下游服务的每秒请求阈值之间的差值；
15.当每秒请求总量超过所述每秒请求阈值时，将当前消息线程的释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长，所述极限执行时长为根据每秒请求阈值计算出的每请求的平均值；
16.当每秒请求总量低于所述每秒请求阈值的一定范围且所述释放时长未归零时，使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短而使当前消息线程持续处于缓释状态。
17.进一步的实施例中，当每秒请求总量超过所述每秒请求阈值时执行的步骤中，包括如下步骤：
18.当每秒请求总量首次超过所述每秒请求阈值时，将预先被初始化为零值的所述释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态；
19.当每秒请求总量连续超过所述每秒请求阈值时，将所述释放时长累加预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长。
20.进一步的实施例中，当每秒请求总量低于所述每秒请求阈值的一定范围且所述释放时长未归零时执行的步骤中，将所述释放时长累减所述预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短。
21.具体化的实施例中，监听预期排队时长的变动，当当前消息线程的预期排队时长超过预设延迟阈值时，控制当前消息线程处于等待同步执行的活跃状态，将其释放时长归零，且，在当前消息线程连续多次处于活跃状态时，将当前消息线程交付异步执行，包括如下步骤：
22.监听获取每次计算所得的预期排队时长；
23.判断所述预期排队时长是否超过预设延迟阈值，当判定为超过时，将当前消息线程的释放时长归零而使当前消息线程处于等待同步执行的活跃状态；
24.判断所述预期排队时长是否连续多次超过所述预设延迟阈值，若是，将当前消息线程交付用于异步消费消息线程的任务线程池以实现异步执行。
25.较佳的实施例中，本方法还包括如下步骤：
26.监测所述任务线程池中的消息线程总量；
27.当任务线程池中的消息线程总量大于预设上限后，阻塞向其中添加所述的消息线程；
28.当持续多次任务线程池中的消息线程总量归零且所述每秒请求总量低于所述每秒请求阈值时，销毁该任务线程池。
29.较佳的实施例中，持续统计从消息队列调度给下游服务的消息线程总量获得每秒
请求总量，计算每个消息线程的平均执行时长，包括如下步骤：
30.每秒定期统计从消息队列调度出列以传递给下游服务而被消费的消息线程的总量，作为所述的每秒请求总量；
31.计算每秒请求总量中每个请求在一秒内平均占用的时隙，将该时隙确定为所述的平均执行时长。
32.为解决上述技术问题，本技术采用的另一技术方案是：
33.本技术提供一种消息调度控制装置，其包括数据获取模块、缓释控制模块、阻塞控制模块以及活跃控制模块，其中，所述数据获取模块，用于持续获取每秒请求总量及其每请求的平均执行时长，所述每秒请求总量通过持续统计从消息队列调度给下游服务的消息线程的总量而获得，所述平均执行时长为根据每秒请求总量计算出的每请求的平均值；所述缓释控制模块，用于监听每秒请求总量的变动，当每秒请求总量超过所述下游服务的每秒请求阈值时，控制当前消息线程处于延缓执行的缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短；所述阻塞统计模块，用于统计当前消息线程相对应的前方阻塞量，根据前方阻塞量与所述平均执行时长的乘积计算当前消息线程对应的预期排队时长；所述活跃控制模块，用于监听预期排队时长的变动，当当前消息线程的预期排队时长超过预设延迟阈值时，控制当前消息线程处于等待同步执行的活跃状态，将其释放时长归零，且，在当前消息线程连续多次处于活跃状态时，将当前消息线程交付异步执行。
34.较佳的实施例中，所述消息队列中的每个所述的消息线程均配置有本装置的各个所述的模块。
35.具体化的实施例中，所述缓释控制模块包括缓释监听子模块，用于监听获取每次统计产生的每秒请求总量，比较每秒请求总量与所述下游服务的每秒请求阈值之间的差值；正向缓释子模块，用于当每秒请求总量超过所述每秒请求阈值时，将当前消息线程的释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长，所述极限执行时长为根据每秒请求阈值计算出的每请求的平均值；反向缓释子模块，用于当每秒请求总量低于所述每秒请求阈值的一定范围且所述释放时长未归零时，使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短而使当前消息线程持续处于缓释状态。
36.进一步的实施例中，所述正向缓释子模块包括：首次缓释二级模块，用于当每秒请求总量首次超过所述每秒请求阈值时，将预先被初始化为零值的所述释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态；连续缓释二级模块，用于当每秒请求总量连续超过所述每秒请求阈值时，将所述释放时长累加预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长。
37.进一步的实施例中，所述反向缓释子模块还用于将所述释放时长累减所述预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短。
38.具体化的实施例中，所述活跃控制模块包括：活跃监听子模块，用于监听获取每次计算所得的预期排队时长；活跃切换二级模块，用于判断所述预期排队时长是否超过预设
延迟阈值，当判定为超过时，将当前消息线程的释放时长归零而使当前消息线程处于等待同步执行的活跃状态；异步交付二级模块，用于判断所述预期排队时长是否连续多次超过所述预设延迟阈值，若是，将当前消息线程交付用于异步消费消息线程的任务线程池以实现异步执行。
39.较佳的实施例中，本装置还包括：总量监测子模块，用于监测所述任务线程池中的消息线程总量；超限阻塞子模块，用于当任务线程池中的消息线程总量大于预设上限后，阻塞向其中添加所述的消息线程；异步回收子模块，用于当持续多次任务线程池中的消息线程总量归零且所述每秒请求总量低于所述每秒请求阈值时，销毁该任务线程池。
40.较佳的实施例中，所述数据获取模块包括：定期统计子模块，用于每秒定期统计从消息队列调度出列以传递给下游服务而被消费的消息线程的总量，作为所述的每秒请求总量；时长计算子模块，用于计算每秒请求总量中每个请求在一秒内平均占用的时隙，将该时隙确定为所述的平均执行时长。
41.为解决上述技术问题，本技术还提供一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行所述消息调度控制方法的步骤。
42.为解决上述技术问题本技术实施例还提供一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行所述消息调度控制方法的步骤。
43.与现有技术相比，本技术具有如下优点：
44.本技术通过在消息线程中植入动态调节机制，使每个消息线程能够根据消息队列的下游服务所处理的每秒请求总量(qps)来对消息线程自身的释放时长进行调节，当通过每秒请求总量发现下游服务的响应速度降低时，延长消息线程自身的释放时长，使得消息队列整体上进入调度减速模式，以缓解下游服务的响应压力；当通过每秒请求总量发现下游服务的响应速度提升时，缩短自身释放时长，使得消息队列整体上进入调度加快模式，从而提升下游服务的处理效率。由此，整个消息队列能够在各个消息线程的动态调节机制的协调控制下，适应下游服务的处理能力变化而实现均衡调度，使消息队列调度效率最大化。
45.本技术在消息队列进入调度加快模式之后，还能根据下游服务的持续响应情况而决定消费线程是否启用异步执行机制，通过异步执行机制来进一步提升下游服务的处理效率，实现消息线程的更快加速处理，确保消息队列的调度效率最大化。
46.概而言之，本技术实现当消息队列中消息线程消费过快时自动降低消费速率保护下游服务，当消费太慢时，自动提升消费速度，缓解消费堆积和延迟处理带来的问题。
附图说明
47.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
48.图1为本技术的消息调度控制方法的典型实施例的流程示意图；
49.图2为本技术的消息调度控制方法消息进程控制状态切换的过程的流程示意图；
50.图3为本技术的消息调度控制方法在调度减速模式下微量调节释放时长的过程的流程示意图；
51.图4为本技术的消息调度控制方法在调度加快模式下启用任务线程池过程的流程示意图；
52.图5为本技术的消息调度控制方法维护任务线程池的过程的流程示意图；
53.图6为本技术的消息调度控制装置的基本结构示意图；
54.图7为本技术一个实施例的计算机设备的基本结构框图。
具体实施方式
55.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本技术，而不能解释为对本技术的限制。
56.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本技术的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
57.本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本技术所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
58.本技术领域技术人员可以理解，这里所使用的“客户端”、“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，进行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他诸如个人计算机、平板电脑之类的通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；pcs(personal communications service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；pda(personal digital assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或gps(global positioning system，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“客户端”、“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“客户端”、“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是pda、mid(mobile internet device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。
59.本技术所称的“服务器”、“客户端”、“服务节点”等名称所指向的硬件，本质上是具备个人计算机等效能力的电子设备，为具有中央处理器(包括运算器和控制器)、存储器、输
入设备以及输出设备等冯诺依曼原理所揭示的必要构件的硬件装置，计算机程序存储于其存储器中，中央处理器将存储在外存中的程序调入内存中运行，执行程序中的指令，与输入输出设备交互，借此完成特定的功能。
60.需要指出的是，本技术所称的“服务器”这一概念，同理也可扩展到适用于服务器机群的情况。依据本领域技术人员所理解的网络部署原理，所述各服务器应是逻辑上的划分，在物理空间上，这些服务器既可以是互相独立但可通过接口调用的，也可以是集成到一台物理计算机或一套计算机机群的。本领域技术人员应当理解这一变通，而不应以此约束本技术的网络部署方式的实施方式。
61.本技术部分技术方案可部署在云端服务器，其可以与业务上相关的服务器实现数据通信连接以协调在线服务，还可与其他相关服务器构成逻辑上相关联的服务机群，来为相关的终端设备例如智能手机、个人计算机、第三方服务器等提供服务。所述的智能手机和个人计算机均可通过公知的网络接入方式接入互联网，与本技术的服务器建立数据通信链路，以便访问和使用所述服务器所提供的服务。
62.对于服务器而言，一般通过提供在线服务的服务引擎开放相应的程序接口供各种终端设备进行远程调用，本技术中适于部署于服务器的相关技术方案，便可以此种方式实现于服务器中。
63.本技术所称的计算机程序，即应用程序，以计算机程序语言开发而成，安装于计算机设备中，包括服务器、终端设备等，用于实现本技术所限定的相关功能，除非特别指定，否则与其所采用的开发语言无关。
64.本领域技术人员对此应当知晓：本技术的各种方法，虽然基于相同的概念而进行描述而使其彼此间呈现共通性，但是，除非特别说明，否则这些方法都是可以独立执行的。同理，对于本技术所揭示的各个实施例而言，均基于同一发明构思而提出，因此，对于相同表述的概念，以及尽管概念表述不同但仅是为了方便而适当变换的概念，应被等同理解。
65.本技术即将揭示的各个实施例，除非明文指出彼此之间的相互排斥关系，否则，各个实施例所涉的相关技术特征可以交叉结合而灵活构造出新的实施例，只要这种结合不背离本技术的创造精神且可满足现有技术中的需求或解决现有技术中的某方面的不足即可。对此变通，本领域技术人员应当知晓。
66.请参阅图1所示本技术的消息调度控制方法在其典型实施例中的基本流程示意图，本技术提供的一种消息调度控制方法，被编程为应用程序运行于计算机设备中，其包括如下步骤：
67.步骤s1100、持续获取每秒请求总量及其每请求的平均执行时长，所述每秒请求总量通过持续统计从消息队列调度给下游服务的消息线程的总量而获得，所述平均执行时长为根据每秒请求总量计算出的每请求的平均值：
68.本技术的每个消息线程当其进入消息队列后，便可开始持续获取下游服务的每秒请求总量qps及根据每秒请求总量计算出的平均执行时长。所述每秒请求总量是消息队列中的消息线程每秒被下游服务消费的总数量，自然地，据此计算出来的每一个消息线程的平均执行时长，反映了下游服务处理对应的每一个请求的平均响应时间长度。
69.为此，可以按照如下的步骤构造一个后台进程，负责实施每秒请求总量及其相应的平均执行时长，该后台进程运行时循环执行如下具体步骤：
70.步骤s1110、每秒定期统计从消息队列调度出列以传递给下游服务而被消费的消息线程的总量，作为所述的每秒请求总量：
71.后台进程按每秒定期循环进行统计，以获取到一秒钟内，由消息队列将消息线程出列实现消费执行，以由下游服务响应相应的请求的总数量，由此构成每秒请求总量qps。
72.步骤s1120、计算每秒请求总量中每个请求在一秒内平均占用的时隙，将该时隙确定为所述的平均执行时长：
73.直接将1秒时长除以所述的每秒请求总量，即得到每个请求平均占用的时隙，该时隙即为平均执行时长。公式表示为：
74.rt＝1/qps
75.步骤s1200、监听每秒请求总量的变动，当每秒请求总量超过所述下游服务的每秒请求阈值时，控制当前消息线程处于延缓执行的缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短：
76.所述下游服务预配置了一个每秒请求阈值maxqps，以指示其每秒钟适于处理的请求总量，而每秒请求总量则代表了当前下游服务实际处理的请求总量，因此，通过比较这两个数值，便可确定下游服务当前的负载情况。
77.对于执行本方法的当前消息线程而言，其对持续产生的每秒请求总量均进行监听，当其获得一次每秒请求总量时，便将该每秒请求总量与下游服务的每秒请求阈值进行比较，然后分别情况进行不同的处理。
78.本实施例中，本步骤旨在适应实现动态调度机制的需要根据每秒请求总量的变动方向而对当前消息线程的缓释状态做出相对应的调节，因此，其根据每秒请求总量的变动方向是增长还是减少而做出不同的具体处理。
79.当前消息线程可以在缓释状态与活跃状态之间的切换，所述的缓释状态是指当前消息线程被控制为延迟被调度消费的状态，而活跃状态则是可以被调度执行的状态，当前消息线程通常设置同一个睡眠时间参数s来表示缓释状态和活跃状态，当睡眠时间参数s＝0时，表示当前消息线程进入活跃状态；当睡眠时间参数为非0值时，表示缓释状态之下睡眠的时长，也即当前消息线程需要等待被释放为可调度消费的释放时长。由此可见，本步骤可以通过控制睡眠时间参数s来实现对当前消息线程的缓释状态及其释放时长的具体控制，具体的控制方式可以参照如下任意一种方式：
80.一种方式中，可以先根据每秒请求阈值maxqps求取其每个请求对应的平均值作为极限执行时长，在此基础上，将其减去根据每秒请求总量计算出的平均执行时长rt，所得的值作为睡眠时间参数s的值，即可用于表示所述的释放时长，公式表示为：
81.s＝(1/maxqps)
–
rt
82.可以看出，极限执行时长1/maxqps是一个常量，由于每秒请求总量是个变量，故其平均执行时长rt也是个变量，当每秒请求总量增大时，rt减小，s表示的释放时长被延长，反之，当每秒请求总量减小时，rt增大，s表示的释放时长被缩短，可以看出，当进入缓释状态时，每次应用前述的公式刷新睡眠时间参数s，均能体现出使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短。
83.可以理解，这一方式由于每次都重新计算并刷新睡眠时间参数s，将释放时长与每秒请求总量的变动强相关，因此，其所起到的控制能力相对是刚性的，其控制效果尚欠弹
性。
84.因此，另一种方式中，可以在前一种方式的基础上，在缓释状态持续进行的阶段，不再每次重新计算上述公式而替换睡眠时间参数s的新值，而是在睡眠时间参数s的原值的基础上，采用一个表示细微时间变化的预设定值来对s进行微调，由此，避免s值的剧烈变动，使释放时长的过渡更为平滑。关于此一方式的其更为具体的过程将在后续的实施例中进一步揭示，此处暂且不表。
85.由此可知，本步骤能够根据每秒请求总量的变动而判别出当前消息线程是否应当进入或维持缓释状态，由此控制当前消息线程在消息队列中按照睡眠时间参数s限定的释放时长保持睡眠，在s＝0时才转换为活跃状态。而睡眠时间参数s或者可以按照前述的第一种方式在每秒请求总量的控制下实现状态切换，或者可以按照前述的第二种方式通过微调来实现状态切换，总之，处于释放状态之下的当前消息线程，能够在每秒请求总量维持增长时被延长睡眠，在每秒请求总量维持减小时被缩短睡眠，起到灵活调节作用，以便最终实现从缓释状态切换回活跃状态。
86.步骤s1300、统计当前消息线程相对应的前方阻塞量，根据前方阻塞量与所述平均执行时长的乘积计算当前消息线程对应的预期排队时长：
87.除了依赖于每秒请求总量的变动来控制处于当前消息线程的释放时长，来达到控制当前消息线程睡眠或停止睡眠，为了实现更为高效的调度效果，本技术还根据当前消息线程的在消息队列中排队前方的阻塞情况来增加对睡眠时间参数s的调节维度。由此，需要统计消息队列中位于当前消息线程前方的消息线程的总量，即其前方阻塞量c。由于在先已经根据每秒请求总量qps计算获得了下游服务处理请求的平均执行时长rt，平均执行时长rt可以供当前消息线程作用预测自身被处理的时长的参考值，因此，可以进一步将前方阻塞量乘以所述的平均执行时长获得乘积，该乘积可以用于表示当前消息线程对应的预期排队时长t，公式表示为：
88.t＝c*rt
89.不难理解，对于消息队列中的每个消息线程而言，由于每个消息线程都会作为当前消息线程执行本技术的技术方案，因此，每个消息线程都能响应每个每秒请求总量而计算获得自身的预期排队时长t。
90.步骤s1400、监听预期排队时长的变动，当当前消息线程的预期排队时长超过预设延迟阈值时，控制当前消息线程处于等待同步执行的活跃状态，将其释放时长归零，且，在当前消息线程连续多次处于活跃状态时，将当前消息线程交付异步执行：
91.为了及时调节所述的睡眠时间参数，以便适应下游服务的对消息线程的实际消化情况而使消息线程的睡眠时间参数得到及时的调整，因此，可预先设置一个预设延迟阈值，预设延迟阈值表示当前消息线程允许最大的延迟时长，据此，每个当前消息线程均可在监听到预期排队时长发生变动之后，决定是否启用加速模式。
92.当前消息线程监听到自身的预期排队时长变动之后，便比较该预期排队时长是否超过所述的预设延迟阈值maxdelay，若预期排队时长超过预设延迟阈值，这种情况应当予以避免，因此，启用调度加速模式，具体的手段可通过将所述的睡眠时间参数设置为零值，即s＝0，表示使当前消息线程激活至活跃状态，以供调度出列进行消费。此一机制相当于对当前消息线程适用了优先策略，因此，必要时，每个消息线程可以根据实际响应需求而配置
自身专有的预设延迟阈值，当其进入消息队列之后，便可根据其预期排队时长与其预设延迟阈值之间的关系，来灵活控制自身在消息队列中的调度节奏。概而言之，睡眠时间参数s＝0时，其释放时长被清零，当前消息线程从缓释状态迅速恢复至活跃状态。
93.为了进一步使当前消息线程得以快速执行，避免停留在当前消息队列中继续等候同步执行而被前方的消息线程阻塞，本技术还允许适应这些急需处理的消息线程而将其交付异步执行。但是，为了避免系统资源的浪费，可以控制异步执行只在特定条件下发生，例如，本实施例中，将在当前消息线程连续多次处于活跃状态时，才触发交付异步执行的机制。判断当前消息线程是否连续多次处于活跃状态，根据当前消息线程的预期排队时长是否多次超过所述延迟预设阈值即可确定，至于连续判断的次数，可由本领域技术人员灵活确定，例如连续5次至20次之间取值，是一个推荐的经验值，可供参考。
94.本实施例中，主要考虑预期排队时长是否超过预设延迟阈值，至于超过的幅度未予考虑，因此，理论上还可以进一步添加一个超过的幅度来构造一个判断的缓冲区间，以便降低对预期排队时长的敏感度，避免调度动作过于频繁而导致增加不必要的额外运行资源消息，为此，本技术后续将通过其他实施例揭示更为丰富的调度方案。
95.概括本实施例，其通过在消息线程中植入动态调节机制，使每个消息线程能够根据消息队列的下游服务所处理的每秒请求总量来对消息线程自身的释放时长进行调节，当通过每秒请求总量发现下游服务的响应速度降低时，延长消息线程自身的释放时长，使得消息队列整体上进入调度减速模式，以缓解下游服务的响应压力；当通过每秒请求总量发现下游服务的响应速度提升时，缩短自身释放时长，使得消息队列整体上进入调度加快模式，从而提升下游服务的处理效率。由此，整个消息队列能够在各个消息线程的动态调节机制的协调控制下，适应下游服务的处理能力变化而实现均衡调度，使消息队列调度效率最大化。
96.本技术在消息队列进入调度加快模式之后，还能根据下游服务的持续响应情况而决定消费线程是否启用异步执行机制，通过异步执行机制来进一步提升下游服务的处理效率，实现消息线程的更快加速处理，确保每个消息线程都能够根据预先配置的预设延迟阈值实现个性化调度，实现优先级管理，确保消息队列的调度效率最大化。
97.请参阅图2，具体化的实施例中，所述步骤s1200，包括如下步骤：
98.步骤s1210、监听获取每次统计产生的每秒请求总量，比较每秒请求总量与所述下游服务的每秒请求阈值之间的差值：
99.当前消息线程监听所述的每秒请求总量的产生，获得每秒请求总量qps，然后将其与下游服务预设的每秒请求阈值进行比较，求取差值即可判断彼此的大小。
100.步骤s1220、当每秒请求总量超过所述每秒请求阈值时，将当前消息线程的释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长，所述极限执行时长为根据每秒请求阈值计算出的每请求的平均值：
101.参考本技术的典型实施例所述，当每秒请求总量超过所述每秒请求阈值时，可通过设置睡眠时间参数s来调节当前消息线程的释放时长，具体是适用前述的公式s＝(1/maxqps)
–
rt，即将其释放时长置为当前消息线程的极限执行时长与下游服务的平均执行时长的差值，所述极限执行时长为根据每秒请求阈值计算出的每请求的平均值1/maxqps，所
述平均执行时长即1/qps，由于qps>maxqps，因此可以理解，此时s值为大于0的正值，表示其释放时长大于0，需要保持相应的睡眠，故而进入了缓释状态。
102.同理，每个消息线程作为当前消息线程时，均可适应每次监听到的每秒请求总量对所述睡眠时间参数s做本实施例的设置操作，由此，便可使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长。
103.一个在此基础上进一步优化的实施例中，如图3所示，所述步骤s1220，包括如下步骤：
104.步骤s1221、当每秒请求总量首次超过所述每秒请求阈值时，将预先被初始化为零值的所述释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态：
105.当消息线程进入消息队列时，其所述的睡眠时间参数s被默认置为零值，只有在当每秒请求总量首次超过所述每秒请求阈值时，才按照前述的公式s＝(1/maxqps)
–
rt设置当前消息线程的释放时长，即将释放时长置为极限执行时长与所述平均执行时长的差值，由此使当前消息线程进入缓释状态，其他时候发现每秒请求总量超过所述每秒请求阈值则进行微调处理。
106.步骤s1222、当每秒请求总量连续超过所述每秒请求阈值时，将所述释放时长累加预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长：
107.当每秒请求总量连续超过所述每秒请求阈值时，也即在每秒请求总量首次超过所述每秒请求阈值之后，又连续发现超过的情况，此时，不必再在适用所述的公式s＝(1/maxqps)
–
rt重新计算，而是在原有的睡眠时间参数s的基础上累加一个预设定值来实现微调即可，所述的预设定值可以由本领域技术人员灵活确定，推荐的经验值例如0.001毫秒，该预设定值所起的作用主要是避免引起释放时长的大幅变动，如果每秒请求总量qps的增长状态得以持续维持，则在每次监听到其维持时在睡眠时间参数s原值的基础上进行微调使释放时长适度延长即可。
108.这一进一步优化的实施例给出了使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长的微调手段，在下游服务持续高压运行时，此举可控制当前消息线程的释放时长平滑变化，从而使整个消息队列的调度更为均衡高效。
109.步骤s1230、当每秒请求总量低于所述每秒请求阈值的一定范围且所述释放时长未归零时，使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短而使当前消息线程持续处于缓释状态：
110.本步骤不同于本技术典型实施例的是，在进行每秒请求总量qps与每秒请求阈值masqps之间的比较时，考虑了双方的差异幅度而为彼此的比较设置一个表征一定范围的缓冲区间，示例而言，本步骤可以判断所述每秒请求总量qps是否低于所述每秒请求阈值的80％，即以每秒请求阈值的20％作为缓冲区间，一方面在前文的步骤中对每秒请求总量超过每秒请求阈值的100％的情况做响应，另一方面在本步骤中可对每秒请求总量低于每秒请求阈值的80％的情况做响应。除此之外，出于考虑控制释放时长以实现状态维持控制的目的，还需考虑联立条件，即考虑当前消息线程的释放时间为非零值，也即当前消息线程的睡眠时间参数s>0且qps<maxqps*80％成立时，才实施此处的控制。
111.具体的控制手段是使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短而使当前消息线程持续处于缓释状态，通过设置当前消息线程的睡眠时间参数s来实现。
112.适应前述以预设定量来实现微调的优化的实施例，本步骤也可做相应的改进，具体而言，可在本步骤中，通过修改睡眠时间参数s将所述释放时长累减所述预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短。
113.通过本实施例及在其基础上优化的各个变化实施例可以看出，本技术在当前消息线程构造进入缓释状态的条件之后，区别其是首次进入缓释状态，还是后续持续处于该缓释状态，并且考虑了避免当前消息线程从缓释状态急速切换到活跃状态而设置了一个判决的缓冲区间，且在部分实施例中适用了微调机制，整体上使整个当前消息线程的睡眠时间参数的调节更为平滑，可避免消息队列内的消息线程频繁发生状态切换，节省计算机运行资源开销，有助于提升计算机设备的运行效率。
114.请参阅图4，具体化的实施例中，所述步骤s1400，包括如下步骤：
115.步骤s1410、监听获取每次计算所得的预期排队时长：
116.本实施例中，消息线程采用监听机制，获取每次计算所得的所述预期排队时长，如前所述，预期排队时长表征当前消息线程在排队前方被阻塞导致的所需的等候时间。
117.步骤s1420、判断所述预期排队时长是否超过预设延迟阈值，当判定为超过时，将当前消息线程的释放时长归零而使当前消息线程处于等待同步执行的活跃状态：
118.导致当前消息线程的释放时长被归零的因素，主要包括下游服务的每秒请求总量降低引起睡眠时间参数s不断下降的情况，以及包括预期排队时长大于预设延迟阈值时的情况，这两种情况下，睡眠时间参数s均有可能回归到零值，从而实现将当前消息线程切换为活跃状态，进入活跃状态的消息线程，便在消息队列中等待直接调度，以实现同步执行。
119.步骤s1430、判断所述预期排队时长是否连续多次超过所述预设延迟阈值，若是，将当前消息线程交付用于异步消费消息线程的任务线程池以实现异步执行：
120.如前所述，判断所述预期排队时长是否连续多次超过所述预设延迟阈值，判断次数可灵活设定，当满足预定次数的多次判定结果之后，确认当前消息线程在当前消息队列中继续等待同步执行将影响访问需求，故此，此时便需启动用于异步消费信息的任务线程池，由该任务线程池负责消费当前消息线程，使当前消息线程实现异步执行，从而避免当前消息线程在原消息队列中被阻塞而无法及时响应。
121.所述任务线程池可按需创建，也可预先配置，本领域技术人员可灵活实施。但为了节省系统开销，需要对任务线程池进行必要的维护，因此，在进一步的实施例中，如图5所示，本方法还包括如下步骤：
122.步骤s1500、监测所述任务线程池中的消息线程总量：
123.可以在后台预置一个任务线程池的服务模块，负责本技术的方法所启用的任务线程池中消息线程的总数量，由此来实施对该任务线程池的维护。
124.步骤s1600、当任务线程池中的消息线程总量大于预设上限后，阻塞向其中添加所述的消息线程：
125.为了实现对任务线程池的维护，避免任务线程池也造成拥塞，一般可为该任务线程池所能处理的消费线程总量预设一个上限值，即预设上限，该预设上限一般小于本技术
的消息队列的队列长度，例如前者为后者的1/10大小，当所述的任务线程池中的消息线程总量大于预设上限后，便可禁止从所述的消息队列中向该任务线程池添加新的消息线程，在这种情况下，即使在所述步骤s1400中希望将一个当前消息线程添加到所述的任务线程池中实现异步进行，也会因被阻塞而导致失败。此举有效维护了任务线程池小巧灵活的优势，也不影响消息队列发挥主要作用，使资源配置更均衡。
126.步骤s1700、当持续多次任务线程池中的消息线程总量归零且所述每秒请求总量低于所述每秒请求阈值时，销毁该任务线程池：
127.任务线程池长期占用系统资源同样也会导致系统资源的浪费，因此，可以响应每次产生所述的每秒请求总量对任务线程池进行空转判断，具体而言，一方面判断是次获得的每秒请求总量是否低于所述每秒请求阈值，若判断成立，表示消息队列不至于拥堵，因而任务线程池存在的必要性不高；另一方面，可以判断所述任务线程池是否不存在任何消息线程，若判断成立，则表示任务线程池当前处于闲置的状态。如果每次进行两方面的判断都成立，则意味着识别到一次任务线程池的空转，连续实施多次这样的判断均确认任务线程池处于空转状态时，则可认定任务线程池可被回收。至于构成判定空转状态的检测总次数，可以由本领域技术人员灵活设定，例如在5至10次中取值，优选10次。
128.出于资源回收以提升设备效率的需要，当确认任务线程池处于空转状态之后，直接销毁该任务线程池即可。
129.本实施例通过建立任务线程池的监控和维护机制，及时回收任务线程池，实现任务线程池的按需启用和空转时销毁，有利于节省系统开销，提升系统运行效率。
130.请参阅图6，本技术实施例还提供一种消息调度控制装置，其包括数据获取模块1100、缓释控制模块1200、阻塞控制模块1300以及活跃控制模块1400，其中，所述数据获取模块1100，用于持续获取每秒请求总量及其每请求的平均执行时长，所述每秒请求总量通过持续统计从消息队列调度给下游服务的消息线程的总量而获得，所述平均执行时长为根据每秒请求总量计算出的每请求的平均值；所述缓释控制模块1200，用于监听每秒请求总量的变动，当每秒请求总量超过所述下游服务的每秒请求阈值时，控制当前消息线程处于延缓执行的缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增减状态的维持而相应延长或缩短；所述阻塞统计模块1300，用于统计当前消息线程相对应的前方阻塞量，根据前方阻塞量与所述平均执行时长的乘积计算当前消息线程对应的预期排队时长；所述活跃控制模块1400，用于监听预期排队时长的变动，当当前消息线程的预期排队时长超过预设延迟阈值时，控制当前消息线程处于等待同步执行的活跃状态，将其释放时长归零，且，在当前消息线程连续多次处于活跃状态时，将当前消息线程交付异步执行。
131.较佳的实施例中，所述消息队列中的每个所述的消息线程均配置有本装置的各个所述的模块。
132.具体化的实施例中，所述缓释控制模块1200包括缓释监听子模块，用于监听获取每次统计产生的每秒请求总量，比较每秒请求总量与所述下游服务的每秒请求阈值之间的差值；正向缓释子模块，用于当每秒请求总量超过所述每秒请求阈值时，将当前消息线程的释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态，且使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长，所述极限执行时长为根据每秒请求阈值计算出的每请求的平均值；反向缓释子模块，用于当每秒请
求总量低于所述每秒请求阈值的一定范围且所述释放时长未归零时，使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短而使当前消息线程持续处于缓释状态。
133.进一步的实施例中，所述正向缓释子模块包括：首次缓释二级模块，用于当每秒请求总量首次超过所述每秒请求阈值时，将预先被初始化为零值的所述释放时长置为极限执行时长与所述平均执行时长的差值而使当前消息线程进入缓释状态；连续缓释二级模块，用于当每秒请求总量连续超过所述每秒请求阈值时，将所述释放时长累加预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的增长状态的维持而相应延长。
134.进一步的实施例中，所述反向缓释子模块还用于将所述释放时长累减所述预设定值实现微调，以使当前消息线程的释放时长根据每秒请求总量的减少状态的维持而相应缩短。
135.具体化的实施例中，所述活跃控制模块1400包括：活跃监听子模块，用于监听获取每次计算所得的预期排队时长；活跃切换二级模块，用于判断所述预期排队时长是否超过预设延迟阈值，当判定为超过时，将当前消息线程的释放时长归零而使当前消息线程处于等待同步执行的活跃状态；异步交付二级模块，用于判断所述预期排队时长是否连续多次超过所述预设延迟阈值，若是，将当前消息线程交付用于异步消费消息线程的任务线程池以实现异步执行。
136.较佳的实施例中，本装置还包括：总量监测子模块，用于监测所述任务线程池中的消息线程总量；超限阻塞子模块，用于当任务线程池中的消息线程总量大于预设上限后，阻塞向其中添加所述的消息线程；异步回收子模块，用于当持续多次任务线程池中的消息线程总量归零且所述每秒请求总量低于所述每秒请求阈值时，销毁该任务线程池。
137.较佳的实施例中，所述数据获取模块1100包括：定期统计子模块，用于每秒定期统计从消息队列调度出列以传递给下游服务而被消费的消息线程的总量，作为所述的每秒请求总量；时长计算子模块，用于计算每秒请求总量中每个请求在一秒内平均占用的时隙，将该时隙确定为所述的平均执行时长。
138.本技术实施例还提供计算机设备。具体请参阅图7，图7为本实施例计算机设备基本结构框图。
139.如图7所示，计算机设备的内部结构示意图。该计算机设备包括通过系统总线连接的处理器、非易失性存储介质、存储器和网络接口。其中，该计算机设备的非易失性存储介质存储有操作系统、数据库和计算机可读指令，数据库中可存储有控件信息序列，该计算机可读指令被处理器执行时，可使得处理器实现一种消息调度控制方法。该计算机设备的处理器用于提供计算和控制能力，支撑整个计算机设备的运行。该计算机设备的存储器中可存储有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行一种消息调度控制方法。该计算机设备的网络接口用于与终端连接通信。本领域技术人员可以理解，图7中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
140.本实施方式中处理器用于执行图6中各个模块/子模块的具体功能，存储器存储有执行上述模块所需的程序代码和各类数据。网络接口用于向用户终端或服务器之间的数据
传输。本实施方式中的存储器存储有消息调度控制装置中执行所有子模块所需的程序代码及数据，服务器能够调用服务器的程序代码及数据执行所有子模块的功能。
141.本技术还提供一种存储有计算机可读指令的存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述任一实施例的消息调度控制方法的步骤。
142.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(read
‑
only memory，rom)等非易失性存储介质，或随机存储记忆体(random access memory，ram)等。
143.综上所述，本技术实现当消息队列中消息线程消费过快时自动降低消费速率保护下游服务，当消费太慢时，自动提升消费速度，缓解消费堆积和延迟处理带来的问题。
144.本技术领域技术人员可以理解，本技术中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本技术中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本技术中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。
145.以上所述仅是本技术的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。