资源请求方法、装置和系统与流程

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.根据所述平均消息处理速度和所述平均消息积压量，确定所述目标资源量。
45.可选地，所述处理模块，具体用于：
46.根据目标资源量和所述资源参数，确定需要资源数量；
47.根据所述资源数量生成所述资源获取请求。
48.可选地，当所述消息处理平台中采用容器化技术部署时，所述资源数量为副本数量，所述资源获取请求用于请求资源管理平台增加所述消息处理平台的副本数量。
49.可选地，当所述消息处理平台中采用非容器化技术部署时，所述资源数量为接口数量，所述资源获取请求用于请求资源管理平台增加所述消息处理平台的接口数量。
50.可选地，所述处理模块，还用于：
51.根据每一周期内的所述消息接收量和所述消息处理量，确定每一周期内的排队占比；
52.统计预设时间段内，所述排队占比大于占比阈值的积压次数；
53.当所述积压次数小于次数阈值时，根据预设值确定所述目标资源量。
54.可选地，所述处理模块，具体用于：
55.根据所述消息接收量和所述消息处理量的差值，确定消息排队量；
56.根据所述消息排队量与所述消息接收量的比值，确定所述排队占比。
57.可选地，所述处理模块，还用于：
58.根据当前周期内的所述消息处理量和周期时长，确定当前消息处理速度；
59.根据所述当前消息处理速度和当前周期内的所述消息接收量，确定消息积压概率；
60.当所述消息积压概率小于概率阈值时，根据预设值确定所述目标资源量。
61.可选地，所述处理模块，具体用于：
62.根据所述消息接收量和所述当前消息处理速度的比值，确定实际处理耗时；
63.根据所述实际处理耗时和所述周期时长的比值，确定所述消息积压概率。
64.可选地，所述处理模块，具体用于：
65.从所述消息处理平台的历史记录中，获取下一周期对应的历史消息接收量；
66.根据所述历史消息接收量和所述当前消息处理速度的比值，确定历史处理耗时；
67.根据所述历史处理耗时和所述周期时长的比值，确定历史积压概率；
68.根据所述消息积压概率和所述历史积压概率的加权和，更新所述消息积压概率。
69.第三方面，本技术提供一种消息处理系统，包括：资源管理平台和至少一个消息处理平台，所述资源管理平台用于管理所述消息处理系统中的的资源，每一所述消息处理平台用于处理一类消息，每一所述消息处理平台对应于至少一个服务器，所述服务器中部署有容器副本或者部署有接口。
70.第四方面，本技术提供一种可读存储介质，可读存储介质中存储有计算机程序，当消息处理平台的至少一个处理器执行该计算机程序时，消息处理平台执行第一方面及第一方面任一种可能的设计中的资源请求方法。
71.第五方面，本技术提供一种计算机程序产品，所述计算机程序产品包括计算机程序，当消息处理平台的至少一个处理器执行该计算机程序时，消息处理平台执行第一方面及第一方面任一种可能的设计中的资源请求方法。
72.本技术提供的资源请求方法，通过周期性统计消息的处理情况，该处理情况包括消息的接收量和消息处理量；在监控得到预设时间段内各个周期内的消息接收量和消息处理量后，周期性的使用该消息接收量和消息处理量计算得到目标资源量；根据的资源参数和该目标资源量进行计算，得到需求请求的资源数量；根据该消息数量，生成资源获取请
求；将该资源获取请求发送到资源管理平台，以使资源管理平台根据该资源获取请求为分配资源的手段，实现提高了资源处理平台的处理效率，通过消息的分流避免积压，避免资源管理平台中资源的浪费效果。
附图说明
73.为了更清楚地说明本技术或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
74.图1为本技术一实施例提供的一种资源请求的系统流程示意图；
75.图2为本技术一实施例提供的一种资源请求方法的流程图；
76.图3为本技术一实施例提供的一种资源请求方法的流程图；
77.图4为本技术一实施例提供的一种资源请求方法的流程图；
78.图5为本技术一实施例提供的一种资源请求装置的结构示意图；
79.图6为本技术一实施例提供的一种消息处理系统的结构示意图。
具体实施方式
80.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术中的附图，对本技术中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
81.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换。例如，在不脱离本文范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。
82.取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
83.再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。
84.应当进一步理解，术语“包含”、“包括”表明存在所述的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。
85.此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。
86.在存在大量消息交互的网络平台中，消息的及时处理是保证平台可靠性和稳定性的重要因素。目前，网络平台可以通过中间件实现消息的中转。在消息处理系统中，该中间件可以在前端将消息发送到后台时，将该消息转发到对应的消息处理平台。jmq是一款具有
高可用性、高可靠性的消息中间件系统。该中间件系统被广泛应用于订单生成、支付处理、库房管理等场景中。
87.在实际使用中，消息处理系统中的消息量是不断变化的。消息处理系统中各个消息处理平台的处理效率是固定的。即消息消费方的消费能力是固定的。此时，随着消息量的增加，可能出现消息处理平台无法及时处理这些消息的情况。该情况可能会进一步导致消息的积压，消息处理异常等问题。
88.现有技术中，资源管理平台可以在检测到消息处理平台的消息产生积压时，发送消息提醒，以提醒管理员对该消息积压的情况进行处理。管理员在接收到该消息提醒后，可以根据消息积压量进行评估，并根据该评估结果生成资源获取请求。该资源获取请求可以向资源管理平台请求为该消息处理平台分配资源，以实现在消息积压时，该消息处理平台的资源的扩展。或者，消息处理平台还可以在检测到消息处理平台的消息产生积压时，根据积压的消息量，生成资源获取请求。
89.然而，使用该方式获取资源通常存在滞后性。消息处理平台通常在消息已经发生积压后才会请求获取资源。该方式容易导致消息处理不及时的问题，可能给用户造成损失，或者给用户带来不好的用户体验。
90.针对上述问题，本技术提出了一种资源请求方法。本技术通过在消息处理平台中设置插件，实现对消息处理平台的消息接收量和消息处理量的周期性统计。该插件还可以在预设时间段内，根据各个周期内的消息接收量和消息处理量判断该消息处理平台是否可能发生消息积压。如果该插件认为该消息处理平台可能发生消息的积压，泽该插件可以根据各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。该目标资源量用于指示该插件预估处理完可能积压的消息所需要的资源。在该消息处理平台中，资源参数通常与处理消息的程序相关。当处理消息的程序运行于容器的副本中，则该消息处理平台的资源参数用于指示一个副本所包括的资源数量。否则，当处理消息的程序通过接口获取消息时，该消息处理平台的资源参数用于指示一个接口所包括的资源数量。该插件可以获取该消息处理平台的该资源参数。该插件还可以根据目标资源量和资源参数，确定需要请求的资源数量。该插件可以根据该需要请求的资源数量，生成资源获取请求。该插件可以将该资源获取请求发送到资源管理平台。
91.本技术可以通过上述方法，提前感知并在有影响扩大苗头时，自动且及时的增加资源，提高消息处理效率，避免消息积压。该方法的使用可以有效防止危害扩大，避免产生不可估量的损失。该方法的使用还可以提升用户体验和系统处理效率，降低人力成本和维护的时间成本。
92.下面以具体地实施例对本技术的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
93.图1示出了本技术一实施例提供的一种资源请求的系统流程示意图。其中，消费端即为消息处理平台，用于处理消息。消息处理平台可以通过安装插件实现对自身的监视。消息处理平台可以根据该监视结果，得到起本身对于消息的处理能力。该消息处理平台还可以根据监视结果，确定消息队列中消息入队情况。该消息处理平台中可以预存储有积压处理规则。当该消息处理队列判断情况满足该积压处理规则时，该消息处理平台可以触发积压处理。在该积压处理过程中，该消息处理平台可以计算所需的资源数量。该消息处理平台
可以想资源管理平台申请资源。当该消息处理平台接受到资源管理平台分配的资源后，该消息处理平台可以进行资源扩展。
94.一种示例中，该资源管理平台为消息处理平台分配的资源，可以为动态资源。消息处理平台可以在获取该资源后的一定时间内使用该资源。当时间超过该一定时间后，该消息处理平台的资源数量恢复初始的资源数量。该资源管理平台分配到该消息处理平台的资源被释放。资源管理平台可以再次将该资源分配到某一消息管理平台。
95.一种示例中，该消息处理平台中可以包括一台管理服务器，该管理服务器中安装有插件。该管理服务器可以获取该消息处理平台需要全部消息，并将这些消息发送到该消息处理平台的其他服务器中进行处理。该管理服务器中的插件可以实现对该消息处理平台的消息的统计。
96.另一种示例中，该消息处理平台中的每一服务器中可以安装有一个统计插件。该统计插件可以用于统计每一服务器中消息的入队情况和处理情况。该消息处理平台中还可以安装有可一个管理插件。该管理插件用于汇总该消息处理平台的全部统计插件的统计结果。
97.本技术中，以消息处理平台为执行主体，执行如下实施例的资源请求方法。具体地，该执行主体可以为消息处理平台的硬件装置，或者为消息处理平台中实现下述实施例的软件应用，或者为安装有实现下述实施例的软件应用的计算机可读存储介质，或者为实现下述实施例的软件应用的代码。
98.图2示出了本技术一实施例提供的一种资源请求方法的流程图。在图1所示实施例的基础上，如图2所示，以消息处理平台为执行主体，本实施例的方法可以包括如下步骤：
99.s101、周期性统计消息处理平台的消息接收量和消息处理量。
100.本实施例中，消息处理平台中可以安装有插件。该插件可以为java-javaagent:messagebacklog.jar。该插件用于监视该消息处理平台中的消息。该插件通常采用启动脚本方式或硬编码方式引入该消息处理平台。该消息处理平台可以通过该插件实现对该消息处理平台的业务系统的编译码的扫描。其中，该业务系统的编译码可以为class字节码。在完成扫描后，该插件还可以自动在该消息处理平台的业务系统中的消息消费方法中增加字节码。其中，消息消费方法是指该消息处理平台中用于实现消息的具体消费过程的函数/方法/类等代码。其中，字节码用于增加逻辑功能。例如，当增加该字节码后，在业务系统中的业务功能执行消息的消费之前和之后，可以加入统计逻辑。即消息处理平台可以在消息处理前对接受到的消息进行统计。该消息处理平台还可以在消息处理后对被处理的消息进行统计。
101.例如，针对项目a，可以包括topic1、topic2等多个消息类型。其中，不同类型的消息可以被分配到不同的消息处理业务平台进行处理。其中，一个消息处理平台可以用于处理至少一种消息类型的消息。
102.消息处理平台可以周期性统计消息的处理情况。该处理情况可以包括消息的接收量和消息处理量。例如，如表1所示，为周期时长为5分钟时，该消息处理平台统计得到的多个周期内的消息处理情况。
103.表1
104.开始时间入队处理结束时间
2021/8/24 14:05300025002021/8/24 14:102021/8/24 14:10350032002021/8/25 14:152021/8/24 14:15200013002021/8/26 14:202021/8/24 14:25300025002021/8/27 14:30
105.s102、根据在预设时间段内，各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。
106.本实施例中，消息处理平台可以在消息出现积压，或者预估到消息可能出现积压时，计算目标资源量。该目标资源量用于指示处理已经积压的消息或者处理预计可能出现积压的消息所需的资源量。消息处理平台可以在监控得到预设时间段内各个周期内的消息接收量和消息处理量后，周期性的使用该消息接收量和消息处理量计算得到目标资源量。
107.一种示例中，该目标资源量的计算过程具体可以包括如下步骤：
108.步骤1、消息处理平台在预设时间段内，根据各个周期内的消息处理量和周期时长，确定平均消息处理速度。
109.本步骤中，消息处理平台可以通过计算该在预设时间段内，每一周期内的消息处理量和周期时长的比值，确定每一周期内的消息处理速度。例如，如表1所示，2021/8/24 14:05至2021/8/24 14:10这一周期内，消息处理速度为2500/5＝500。消息处理平台可以通过计算该在预设时间段内各个周期内的消息处理速度，计算其均值，得到平均消息处理速度。例如，如表1所示，在预设时间段2021/8/24 14:05至2021/8/24 14:25内，各个周期内的消息处理速度分别为500、640、260、500。其平均消息处理速度可以为(500 640 260 500)/4＝475。
110.或者，消息处理平台还可以通过统计该预设时间段内的总消息处理量，并计算该总消息处理量与该预设时间段的时长的比值，确定该平均消息处理速度。例如，如表1所示，在预设时间段2021/8/24 14:05至2021/8/24 14:25内，总消息处理量为9500。平均消息处理速度为9500/20＝475。
111.步骤2、消息处理平台在预设时间段内，根据各个周期内的消息接收量和消息处理量，确定平均消息积压量。
112.本步骤中，消息处理平台可以通过计算该在预设时间段内，每一周期内的消息接收量和消息处理量的差值，确定每一周期内的消息积压量。例如，如表1所示，2021/8/24 14:05至2021/8/24 14:10这一周期内，消息积压量为3000-2500＝500。消息处理平台可以通过计算该在预设时间段内各个周期内的消息积压量，计算其均值，得到平均消息积压量。例如，如表1所示，在预设时间段2021/8/24 14:05至2021/8/24 14:25内，各个周期内的消息积压量分别为500、300、700、500。其平均消息积压量可以为(500 300 700 500)/4＝500。
113.或者，消息处理平台还可以通过统计该预设时间段内的总消息接收量和总消息处理量后，根据其差值计算总消息积压量。例如，如表1所示，在预设时间段2021/8/24 14:05至2021/8/24 14:25内，总消息接收量为11500，总消息处理量为9500。消息处理平台可以计算得到总消息积压量为11500-9500＝2000。其平均消息积压量可以为2000/4＝500。
114.步骤3、消息处理平台根据平均消息处理速度和平均消息积压量，确定目标资源量。
115.本步骤中，消息处理平台可以根据上述两个步骤中分别计算得到的平均消息处理
速度和平均消息积压量，计算得到目标资源量。该目标资源量的计算公式可以为：
116.目标资源量＝平均消息积压量/平均消息处理速度
117.该目标资源量可以理解为该消息处理平台的当前资源处理完积压消息所需要的处理时间。
118.s103、根据目标资源量和消息处理平台的资源参数，生成并发送资源获取请求，资源获取请求用于向资源管理平台请求资源。
119.本实施例中，由于该消息处理平台一直处于工作状态，因此，该消息处理平台无法处理这些积压的消息。为了使这些积压的消息被处理，资源管理服务器需要为该消息处理平台分配资源，以提高该消息处理平台的处理能力。消息处理平台可以根据消息处理平台的资源参数和该目标资源量进行计算，得到需求请求的资源数量。该消息处理平台可以根据该消息数量，生成资源获取请求。该消息处理平台可以将该资源获取请求发送到资源管理平台。资源管理平台根据该资源获取请求为消息处理平台分配资源。
120.一种示例中，消息处理平台根据目标资源量和资源参数生成资源获取请求的具体步骤可以包括：
121.步骤1、消息处理平台根据目标资源量和资源参数，确定需要资源数量。
122.本步骤中，目标资源量可以理解为使用消息处理平台的当前资源处理完积压消息所需要的时间。当时长为单位时长时，根据该目标资源量，还可以计算得到在单位时长内处理完成该积压消息所需要的资源。
123.一种实现方式中，当消息处理平台中采用容器化技术部署时，该消息处理平台中资源的最小单位为副本。该资源的数量可以使用副本的数量进行描述。资源参数用于描述每一副本中的资源。消息处理平台可以根据在单位时长内处理完成该积压消息所需要的资源与资源参数的比值，确定需要增加的资源数量。该资源数量为副本数量。即，当该消息处理平台中增加资源数量个副本时，该积压消息可以在单位时间内被处理掉。
124.另一种实现方式中，当消息处理平台中采用非容器化技术部署时，该消息处理平台中资源的最小单位为接口。该资源的数量可以使用接口的数量进行描述。资源参数用于描述每一接口中的资源。消息处理平台可以根据在单位时长内处理完成该积压消息所需要的资源与资源参数的比值，确定需要增加的资源数量。该资源数量为接口数量。当该消息处理平台中增加资源数量个接口时，该积压消息可以在单位时间内被处理掉。
125.步骤2、消息处理平台根据资源数量生成资源获取请求。
126.本步骤中，消息处理平台可以根据上一步骤计算得到的资源数量，生成资源获取请求。
127.一种实现方式中，当消息处理平台中采用容器化技术部署时，资源获取请求用于请求资源管理平台增加消息处理平台的副本数量。
128.另一种实现方式中，当消息处理平台中采用非容器化技术部署时，资源获取请求用于请求资源管理平台增加消息处理平台的接口数量。
129.一种示例中，当消息处理平台中采用容器化技术部署时，每一服务器中可以运行有至少一个容器。每一容器中部署有至少一个副本。当该消息处理平台中还存在一些空闲资源时，该消息处理平台可以通过增加副本数量的方式，增加该消息处理平台中可以用于消息处理的资源。例如，该消息处理平台可以通过下述指令采用滚动升级的方式实现资源
数提升。
130.kubectl scale deployment nginx-deployment
‑‑
replicas 5
131.其中，该指令用于指示修改容器中副本的数量。其中，
‑‑
replicas 5用于指示将副本数量修改为5。-deployment用于指示该消息处理平台对应的项目的部署文件。
132.另一种示例中，当消息处理平台中采用非容器化技术部署时，每一服务器中可以运行有至少一个接口程序。消息处理平台可以通过运行一个接口程序实现一个接口的使用。资源管理平台可以将新分配的服务器的地址发送到消息处理平台。消息处理平台可以通过如下远程控制代码，实现链接到该服务器，以及将本地信息存储到该服务器中。
133.scp-p 22remote@www.test.com:/usr/local/test.jar/home/export
134.其中，消息处理平台可以链接到www.test.com这一服务器上，并将本地信息存放在/usr/local/test.jar/home/export目录下面。其中，scp-p 22remote为远程控制指令。上述操作用于实现该新分配的服务器的远程部署。当完成部署后，该服务器中的
135.当完成本地文件的远程部署后，该消息处理平台可以可以通过脚本指令./start.sh，实现该接口的启动。
136.本技术提供的资源请求方法，消息处理平台可以周期性统计消息的处理情况。该处理情况可以包括消息的接收量和消息处理量。消息处理平台可以在监控得到预设时间段内各个周期内的消息接收量和消息处理量后，周期性的使用该消息接收量和消息处理量计算得到目标资源量。消息处理平台可以根据消息处理平台的资源参数和该目标资源量进行计算，得到需求请求的资源数量。该消息处理平台可以根据该消息数量，生成资源获取请求。该消息处理平台可以将该资源获取请求发送到资源管理平台。资源管理平台根据该资源获取请求为消息处理平台分配资源。本技术中，通过在消息出现积压时为该资源处理平台增加资源数量，实现提高了资源处理平台的处理效率，通过消息的分流避免积压，避免资源管理平台中资源的浪费。
137.图3示出了本技术一实施例提供的一种资源请求方法的流程图。在图2实施例的基础上，如图3所示，以消息处理平台为执行主体，本实施例的方法可以包括如下步骤：
138.s201、周期性统计消息处理平台的消息接收量和消息处理量。
139.其中，步骤s201与图2实施例中的步骤s101实现方式类似，本实施例此处不再赘述。
140.s202、根据每一周期内的消息接收量和消息处理量，确定每一周期内的排队占比。
141.本实施例中，消息处理平台可以在每一周期统计得到的消息接收量和消息处理量后，根据该周期内的消息接收量和消息处理量，计算该周期内的排队占比。该排队占比可以用于指示该周期结束时，还没有处理完的消息与该周期入队的消息的比值。
142.一种示例中，该排队占比的计算过程具体可以包括如下步骤：
143.步骤1、消息处理平台根据消息接收量和消息处理量的差值，确定消息排队量。
144.步骤2、消息处理平台根据消息排队量与消息接收量的比值，确定排队占比。
145.s203、统计预设时间段内，排队占比大于占比阈值的积压次数。
146.本实施例中，消息处理平台中可以预设有一些统计规则。这些统计规则可以用于判断是否出现消息积压情况或者是否可能出现消息积压情况。例如，该统计规则可以用于统计预设时间段内排队占比大于占比阈值的积压次数。统计规则中还可以预设有次数阈
值。消息处理平台中可以通过比较积压次数和次数阈值，实现对是否出现消息积压情况的判断。当积压次数小于次数阈值时，消息处理平台可以继续执行步骤s204。当消息积压次数大于等于次数阈值时，消息处理平台可以继续执行步骤s205。例如，该次数阈值可以为2次、3次等。其中，预设时间段可以根据系统精度确定。当系统需要保持较高精度和稳定程度时，该预设时间段可以为2分钟。当系统可以使用较低精度和稳定程度时，该预设时间段可以为5分钟。
147.s204、当积压次数小于次数阈值时，根据预设值确定目标资源量。
148.本实施例中，当积压次数小于预设次数时，可以认为该消息处理平台中的消息没有发生积压。因此，消息处理凭条可以确定目标资源量为预设值。该预设值可以为0、-1等参数，用于指示该情况下消息处理凭条不需要请求资源。当执行该到步骤时，该周期的计算结束。
149.s205、当消息积压次数大于等于次数阈值时，根据在预设时间段内，各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。
150.s206、根据目标资源量和消息处理平台的资源参数，生成并发送资源获取请求，资源获取请求用于向资源管理平台请求资源。
151.其中，步骤s205和s206与图2实施例中的步骤s102和s103实现方式类似，本实施例此处不再赘述。
152.本技术提供的资源请求方法，消息处理平台可以周期性统计消息的处理情况。该处理情况可以包括消息的接收量和消息处理量。消息处理平台可以根据每一周期内的消息接收量和消息处理量，确定每一周期内的排队占比。消息处理平台可以统计预设时间段内，排队占比大于占比阈值的积压次数。当积压次数小于次数阈值时，消息处理平台可以结束该周期的计算。当消息积压概率大于等于概率阈值时，消息处理平台可以根据在预设时间段内，各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。消息处理平台可以根据消息处理平台的资源参数和该目标资源量进行计算，得到需求请求的资源数量。该消息处理平台可以根据该消息数量，生成资源获取请求。本技术中，通过在消息出现积压时为该资源处理平台增加资源数量，实现提高了资源处理平台的处理效率，通过消息的分流避免积压。本技术中，该资源处理平台还可以通过判断是否出现积压，实现在出现积压的时候及时请求资源，避免资源管理平台中资源的浪费。
153.图4示出了本技术一实施例提供的一种资源请求方法的流程图。在图2和图3实施例的基础上，如图4所示，以消息处理平台为执行主体，本实施例的方法可以包括如下步骤：
154.s301、周期性统计消息处理平台的消息接收量和消息处理量。
155.其中，步骤s301与图2实施例中的步骤s101实现方式类似，本实施例此处不再赘述。
156.s302、根据当前周期内的消息处理量和周期时长，确定当前消息处理速度。
157.本实施例中，消息处理平台可以统计当前周期内的消息处理量。消息处理平台可以根据该消息处理量和周期时长的比值，确定当前周期内的当前消息处理速度。
158.s303、根据当前消息处理速度和当前周期内的消息接收量，确定消息积压概率。
159.本实施例中，消息处理平台还可以统计当前周期内的消息接收量。消息处理平台可以根据该当前周期的当前消息处理速度和当前周期内的消息接收量的比值，确定实际处
理耗时。消息处理平台还可以根据该实际处理耗时与周期时长的比值，确定该消息积压概率。当消息处理平台可以在周期内处理完全部消息时，该消息积压概率为一个小于等于1的值。当消息处理平台无法在周期内处理完全部消息时，该消息积压概率为一个大于1的值。
160.一种示例中，消息处理平台还可以获取当前周期的下一周期对应的历史消息接收量。例如，当前周期为2021/8/24 14:05至2021/8/24 14:10时。当前周期的下一周期为2021/8/24 14:10至2021/8/24 14:15。历史消息接收量可以为2021/8/23 14:10至2021/8/23 14:15这一周期内的消息接收量。消息处理平台可以根据历史消息接收量和当前消息处理速度的比值，确定历史处理耗时。消息处理平台可以根据历史处理耗时和周期时长的比值，确定历史积压概率。该历史积压概率大于1时，表示该消息处理平台无法在周期时长内处理该周期内入队的全部消息。当历史积压概率小于1时，表示该消息处理平台可以在周期时长内处理该周期内入队的全部消息。消息处理平台中可以预设有消息积压概率和历史积压概率的权重。消息处理平台中可以根据消息积压概率和历史积压概率的加权和，计算得到新的消息积压概率。
161.另一种示例中，消息处理平台还可以获取多个历史时段中的多个历史消息接收量。消息处理平台可以根据这些历史消息接收量，计算得到多个历史处理耗时。消息处理平台可以根据这些历史处理耗时计算得到的平均历史处理耗时，以及平均历史积压概率。消息处理平台中可以根据消息积压概率和平均历史积压概率的加权和，计算得到新的消息积压概率。消息处理平台中还可以存储有概率阈值。当消息积压概率小于该概率阈值时，消息处理平台可以继续执行步骤s304。当消息积压概率大于等于概率阈值时，消息处理平台可以继续执行步骤s305。例如，该概率阈值可以为1.2、1.3等。
162.s304、当消息积压概率小于概率阈值时，根据预设值确定目标资源量。
163.本实施例中，当消息积压概率小于概率阈值时，可以认为该消息处理平台中的消息没有发生积压。因此，消息处理凭条可以确定目标资源量为预设值。该预设值可以为0、-1等参数，用于指示该情况下消息处理凭条不需要请求资源。当执行该到步骤时，该周期的计算结束。
164.s305、当消息积压概率大于等于概率阈值时，根据在预设时间段内，各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。
165.s306、根据目标资源量和消息处理平台的资源参数，生成并发送资源获取请求，资源获取请求用于向资源管理平台请求资源。
166.其中，步骤s305和s306与图2实施例中的步骤s102和s103实现方式类似，本实施例此处不再赘述。
167.本技术提供的资源请求方法，消息处理平台可以周期性统计消息的处理情况。该处理情况可以包括消息的接收量和消息处理量。消息处理平台可以统计当前周期内的消息处理量。消息处理平台可以根据该消息处理量和周期时长的比值，确定当前周期内的当前消息处理速度。消息处理平台还可以统计当前周期内的消息接收量。消息处理平台可以根据该当前周期的当前消息处理速度和当前周期内的消息接收量的比值，确定实际处理耗时。消息处理平台还可以根据该实际处理耗时与周期时长的比值，确定该消息积压概率。当消息积压概率小于概率阈值时，消息处理平台可以结束该周期的计算。当消息积压概率大于等于概率阈值时，消息处理平台可以根据在预设时间段内，各个周期内的消息接收量、消
息处理量和预设算法，计算得到目标资源量。消息处理平台可以根据消息处理平台的资源参数和该目标资源量进行计算，得到需求请求的资源数量。该消息处理平台可以根据该消息数量，生成资源获取请求。本技术中，通过在消息出现积压时为该资源处理平台增加资源数量，实现提高了资源处理平台的处理效率，通过消息的分流避免积压。本技术中，该资源处理平台还可以通过判断是否出现积压，实现在出现积压的时候及时请求资源，避免资源管理平台中资源的浪费。
168.图5示出了本技术一实施例提供的一种资源请求装置的结构示意图，如图5所示，本实施例的资源请求装置10用于实现上述任一方法实施例中对应于消息处理平台的操作，本实施例的资源请求装置10包括：
169.获取模块11，用于周期性统计消息处理平台的消息接收量和消息处理量。
170.处理模块12，用于根据在预设时间段内，各个周期内的消息接收量、消息处理量和预设算法，计算得到目标资源量。根据目标资源量和消息处理平台的资源参数，生成并发送资源获取请求，资源获取请求用于向资源管理平台请求资源。
171.一种示例中，处理模块12，具体用于：
172.在预设时间段内，根据各个周期内的消息处理量和周期时长，确定平均消息处理速度。
173.在预设时间段内，根据各个周期内的消息接收量和消息处理量，确定平均消息积压量。
174.根据平均消息处理速度和平均消息积压量，确定目标资源量。
175.一种示例中，处理模块12，具体用于：
176.根据目标资源量和资源参数，确定需要资源数量。
177.根据资源数量生成资源获取请求。
178.一种示例中，当消息处理平台中采用容器化技术部署时，资源数量为副本数量，资源获取请求用于请求资源管理平台增加消息处理平台的副本数量。
179.一种示例中，当消息处理平台中采用非容器化技术部署时，资源数量为接口数量，资源获取请求用于请求资源管理平台增加消息处理平台的接口数量。
180.一种示例中，处理模块12，还用于：
181.根据每一周期内的消息接收量和消息处理量，确定每一周期内的排队占比。
182.统计预设时间段内，排队占比大于占比阈值的积压次数。
183.当积压次数小于次数阈值时，根据预设值确定目标资源量。
184.一种示例中，处理模块12，具体用于：
185.根据消息接收量和消息处理量的差值，确定消息排队量。
186.根据消息排队量与消息接收量的比值，确定排队占比。
187.一种示例中，处理模块12，还用于：
188.根据当前周期内的消息处理量和周期时长，确定当前消息处理速度。
189.根据当前消息处理速度和当前周期内的消息接收量，确定消息积压概率。
190.当消息积压概率小于概率阈值时，根据预设值确定目标资源量。
191.一种示例中，处理模块12，具体用于：
192.根据消息接收量和当前消息处理速度的比值，确定实际处理耗时。
193.根据实际处理耗时和周期时长的比值，确定消息积压概率。
194.一种示例中，处理模块12，具体用于：
195.从消息处理平台的历史记录中，获取下一周期对应的历史消息接收量。
196.根据历史消息接收量和当前消息处理速度的比值，确定历史处理耗时。
197.根据历史处理耗时和周期时长的比值，确定历史积压概率。
198.根据消息积压概率和历史积压概率的加权和，更新消息积压概率。
199.本技术实施例提供的资源请求装置10，可执行上述方法实施例，其具体实现原理和技术效果，可参见上述方法实施例，本实施例此处不再赘述。
200.图6示出了本技术实施例提供的一种消息处理系统的结构示意图。如图6所示，该消息处理系统20可以包括：资源管理平台21和至少一个消息处理平台22。
201.其中，一个消息处理系统可以对应于一个应用场景。例如，该消息处理系统可以为网购商城的消息处理系统。又如，该消息处理系统可以为短视频网站的消息处理系统。
202.一个消息处理系统20中可以包括一个资源管理平台21。该资源管理平台21用于管理该消息处理系统20中的全部资源。其中，该资源管理平台21可以对应于一台专用的服务器。或者，该资源管理平台21可以为运行于一台服务器上的一个程序。该程序可以通过接口访问。
203.一个消息处理系统20中可以包括至少一个消息处理平台22。每一消息处理平台22可以用于处理至少一种类型的消息。例如，第一消息处理平台可以用于处理订单生成的消息。第二消息处理平台可以用于处理支付相关的消息。第三消息处理平台可以用于处理库存相关的消息。每一个消息处理平台22中可以包括至少一个服务器。当资源的最小单位为容器中的副本时，每一服务器中可以运行有至少一个容器的副本。当资源的最小单位为接口时，每一服务器中可以运行有至少一个接口程序。
204.一种示例中，该消息处理系统20中还可以包括消息转发平台。客户端可以将消息发送到消息转发平台。该消息转发平台可以根据消息类型，将消息对应分配到消息处理平台22。当一消息处理平台22包括多个接口或者副本时，该消息转发平台可以将多个消息均匀的分配到该消息处理平台22的多个接口或者副本中。
205.本实施例提供的消息处理平台可用于执行上述的资源请求方法，其实现方式和技术效果类似，本实施例此处不再赘述。
206.本技术还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时用于实现上述的各种实施方式提供的方法。
207.其中，计算机可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如，计算机可读存储介质耦合至处理器，从而使处理器能够从该计算机可读存储介质读取信息，且可向该计算机可读存储介质写入信息。当然，计算机可读存储介质也可以是处理器的组成部分。处理器和计算机可读存储介质可以位于专用集成电路(application specific integrated circuits，asic)中。另外，该asic可以位于用户设备中。当然，处理器和计算机可读存储介质也可以作为分立组件存在于通信设备中。
208.具体地，该计算机可读存储介质可以是由任何类型的易失性或非易失性存储设备
或者它们的组合实现，如静态随机存取存储器(static random-access memory，sram)，电可擦除可编程只读存储器(electrically-erasable programmable read-only memory，eeprom)，可擦除可编程只读存储器(erasable programmable read only memory，eprom)，可编程只读存储器(programmable read-only memory，prom)，只读存储器(read-only memory，rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
209.本技术还提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。设备的至少一个处理器可以从计算机可读存储介质中读取该计算机程序，至少一个处理器执行该计算机程序使得设备实施上述的各种实施方式提供的方法。
210.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
211.其中，各个模块可以是物理上分开的，例如安装于一个的设备的不同位置，或者安装于不同的设备上，或者分布到多个网络单元上，或者分布到多个处理器上。各个模块也可以是集成在一起的，例如，安装于同一个设备中，或者，集成在一套代码中。各个模块可以以硬件的形式存在，或者也可以以软件的形式存在，或者也可以采用软件加硬件的形式实现。本技术可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
212.当各个模块以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，平台，或者网络设备等)或处理器执行本技术各个实施例方法的部分步骤。
213.应该理解的是，虽然上述实施例中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
214.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制。尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换。而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。

技术特征：
1.一种资源请求方法，其特征在于，应用于消息处理平台，所述方法，包括：周期性统计所述消息处理平台的消息接收量和消息处理量；根据在预设时间段内，各个周期内的所述消息接收量、所述消息处理量和预设算法，计算得到目标资源量；根据所述目标资源量和所述消息处理平台的资源参数，生成并发送资源获取请求，所述资源获取请求用于向资源管理平台请求资源。2.根据权利要求1所述的方法，其特征在于，所述根据在预设时间段内，各个周期内的所述消息接收量、所述消息处理量和预设算法，计算得到目标资源量，包括：在预设时间段内，根据各个周期内的所述消息处理量和周期时长，确定平均消息处理速度；在预设时间段内，根据各个周期内的所述消息接收量和所述消息处理量，确定平均消息积压量；根据所述平均消息处理速度和所述平均消息积压量，确定所述目标资源量。3.根据权利要求1所述的方法，其特征在于，所述根据所述目标资源量和所述消息处理平台的资源参数，生成资源获取请求，包括：根据目标资源量和所述资源参数，确定需要的资源数量；根据所述资源数量生成所述资源获取请求。4.根据权利要求3所述的方法，其特征在于，当所述消息处理平台中采用容器化技术部署时，所述资源数量为副本数量，所述资源获取请求用于请求资源管理平台增加所述消息处理平台的副本数量；或者，当所述消息处理平台中采用非容器化技术部署时，所述资源数量为接口数量，所述资源获取请求用于请求资源管理平台增加所述消息处理平台的接口数量。5.根据权利要求1-4中任一项所述的方法，其特征在于，在根据在预设时间段内，各个周期内的所述消息接收量、所述消息处理量和预设算法，计算得到目标资源量之前，所述方法，还包括：根据每一周期内的所述消息接收量和所述消息处理量，确定每一周期内的排队占比；统计预设时间段内，所述排队占比大于占比阈值的积压次数；当所述积压次数小于次数阈值时，根据预设值确定所述目标资源量。6.根据权利要求5所述的方法，其特征在于，所述根据每一周期内的所述消息接收量和所述消息处理量，确定每一周期内的排队占比，包括：根据所述消息接收量和所述消息处理量的差值，确定消息排队量；根据所述消息排队量与所述消息接收量的比值，确定所述排队占比。7.根据权利要求1-4中任一项所述的方法，其特征在于，在根据在预设时间段内，各个周期内的所述消息接收量、所述消息处理量和预设算法，计算得到目标资源量之前，所述方法，还包括：根据当前周期内的所述消息处理量和周期时长，确定当前消息处理速度；根据所述当前消息处理速度和当前周期内的所述消息接收量，确定消息积压概率；当所述消息积压概率小于概率阈值时，根据预设值确定所述目标资源量。8.根据权利要求7所述的方法，其特征在于，所述根据所述当前消息处理速度和当前周
期内的所述消息接收量，确定消息积压概率，包括：根据所述消息接收量和所述当前消息处理速度的比值，确定实际处理耗时；根据所述实际处理耗时和所述周期时长的比值，确定所述消息积压概率。9.根据权利要求8所述的方法，其特征在于，所述方法，还包括：从所述消息处理平台的历史记录中，获取下一周期对应的历史消息接收量；根据所述历史消息接收量和所述当前消息处理速度的比值，确定历史处理耗时；根据所述历史处理耗时和所述周期时长的比值，确定历史积压概率；根据所述消息积压概率和所述历史积压概率的加权和，更新所述消息积压概率。10.一种消息处理系统，其特征在于，所述系统，包括：资源管理平台和至少一个消息处理平台，所述资源管理平台用于管理各个所述消息处理平台的资源，每一所述消息处理平台用于处理一类消息，每一所述消息处理平台对应于至少一个服务器，所述服务器中部署有容器副本或者部署有接口。11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时用于实现如权利要求1-9中任一项所述的资源请求方法。

技术总结
本申请提供一种资源请求方法、装置和系统。该方法包括：消息处理平台可以周期性统计消息的处理情况。该处理情况可以包括消息的接收量和消息处理量。消息处理平台可以在监控得到预设时间段内各个周期内的消息接收量和消息处理量后，周期性的使用该消息接收量和消息处理量计算得到目标资源量。消息处理平台可以根据消息处理平台的资源参数和该目标资源量进行计算，得到需求请求的资源数量。该消息处理平台可以根据该消息数量，生成资源获取请求。该消息处理平台可以将该资源获取请求发送到资源管理平台，以使资源管理平台根据该资源获取请求为消息处理平台分配资源。本申请的方法，增加了消息处理效率，避免了消息的积压。避免了消息的积压。避免了消息的积压。


技术研发人员：梁威 岳晓敏 韩金魁
受保护的技术使用者：北京京东乾石科技有限公司
技术研发日：2022.02.21
技术公布日：2022/5/25