CN110460676B - 请求量控制方法、装置、存储介质和计算机设备 - Google Patents

Abstract

本申请涉及一种请求量控制方法、装置、存储介质和计算机设备，所述方法包括：获取当前时间窗口的请求量信息；根据所述请求量信息从额度分配服务器获得当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的请求量信息动态确定；在从获得所述当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在所述当前请求量额度内。本申请提供的方案可以提高请求量的控制效率。

Description

请求量控制方法、装置、存储介质和计算机设备

技术领域

本申请涉及互联网技术领域，特别是涉及一种请求量控制方法、装置、存储介质和计算机设备。

背景技术

随着互联网技术的发展，基于互联网的业务系统越来越普及，人们足不出户就可以在线访问业务系统进行业务活动，给人们的生活带来了诸多便捷。若大量用户同时访问业务系统会存在请求量激增的情况，服务器会在瞬间接收到巨大的请求流量，对服务器造成冲击，从而有可能导致服务器因负载过高而雪崩或宕机。服务器基于所分配的请求量额度对请求量进行控制，通常可以避免或缓解因负载过高而雪崩或宕机的问题。

目前，请求量额度通常是基于服务器的机型静态分配的。该种分配方式下，若存在服务器异常下线或需要新增服务器，需要人工基于繁琐的操作重新分配请求量额度，导致请求量额度更新不及时，从而存在请求量控制效率低的问题。

发明内容

基于此，有必要针对请求量控制效率低的技术问题，提供一种请求量控制方法、装置、存储介质和计算机设备。

一种请求量控制方法，应用于业务服务器集群中的业务服务器，所述方法包括：

获取当前时间窗口的请求量信息；

根据所述请求量信息从额度分配服务器获得当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的请求量信息动态确定；

在从获得所述当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在所述当前请求量额度内。

一种请求量控制装置，所述装置包括：

获取模块，用于获取当前时间窗口的请求量信息；

分配模块，用于根据所述请求量信息从额度分配服务器获得当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的请求量信息动态确定；

控制模块，用于在从获得所述当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在所述当前请求量额度内。

一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述请求量控制方法的步骤。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述请求量控制方法的步骤。

上述请求量控制方法、装置、存储介质和计算机设备，业务服务器集群中的每个业务服务器获取当前时间窗的请求量信息并上报至额度分配服务器，额度分配服务器基于该上报的请求量信息动态给每个业务服务器分配当前请求量额度。由此，各业务服务器的当前请求量额度是基于当前时间窗口对应的请求量信息自动动态分配的，无需人为干预，能够提高当前请求量额度分配的效率和准确性。业务服务器基于所分配的请求量额度，对当前时间后的一定时间段内每个时间片内的请求量进行控制，以避免业务服务器因负载过高而雪崩或宕机的问题。这样，基于当前时间窗口的请求量信息动态确定下一时间段内各时间片的请求量额度，并基于请求量额度进行请求量控制，能够提高请求量的控制效率。

一种请求量控制方法，所述方法包括：

接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息；

根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度；

将所述当前请求量额度反馈至相应的业务服务器；反馈的所述当前请求量额度用于指示相应的业务服务器基于所述当前请求量额度进行请求量控制。

一种请求量控制装置，所述装置包括：

接收模块，用于接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息；

分配模块，用于根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度；

反馈模块，用于将所述当前请求量额度反馈至相应的业务服务器；反馈的所述当前请求量额度用于指示相应的业务服务器基于所述当前请求量额度进行请求量控制。

一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述请求量控制方法的步骤。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述请求量控制方法的步骤。

上述请求量控制方法、装置、存储介质和计算机设备，额度分配服务器接收业务服务器集群中每个业务服务器分别上报的当前时间窗口的请求量信息，并基于该上报的请求量信息和待分配的请求量总额度动态给每个业务服务器分配当前请求量额度，由此基于当前时间窗口的请求量信息自动动态分配当前请求量额度，而无需人工干预，能够提高请求量额度的分配效率。额度分配服务器将自动分配的当前请求量额度反馈至各业务服务器，以使得各业务服务器基于所分配的当前请求量额度进行请求量控制，从而能够提高请求量的控制效率。

附图说明

图1a为一个实施例中请求量控制方法的应用环境图；

图1b为一个实施例中业务服务器集群的架构图；

图2为一个实施例中请求量控制方法的流程示意图；

图3为一个实施例中当前时间窗口的结构示意图；

图4为另一个实施例中当前时间窗口的结构示意图；

图5为另一个实施例中请求量控制方法的流程示意图；

图6为又一个实施例中请求量控制方法的流程示意图；

图7为一个实施例中请求量控制系统的架构图；

图8为另一个实施例中请求量控制系统的架构图；

图9为又一个实施例中请求量控制系统的架构图；

图10为一个实施例中请求量控制装置的结构框图；

图11为另一个实施例中请求量控制装置的结构框图；

图12为一个实施例中计算机设备的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

图1a为一个实施例中请求量控制方法的应用环境图。参照图1a，该请求量控制方法应用于请求量控制系统。该请求量控制系统包括业务服务器集群110和额度分配服务器120。业务服务器集群110至少包括业务服务器112和业务服务器114。业务服务器集群110中的每个业务服务器与额度分配服务器120通过网络连接。服务器集群110中的每个业务服务器和额度分配服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

图1b为一个实施例中请求量控制系统中业务服务器集群的架构图。其中，业务服务器集群110具体可以是区块链网络，业务服务器集群中的每个业务服务器为该区块链网络中的区块链节点服务器。参照图1b，区块链网络至少包括区块链节点服务器112、区块链节点服务器114、…、区块链节点服务器11n。区块链网络中的各个区块链节点服务器通过网络进行通信。

如图2所示，在一个实施例中，提供了一种请求量控制方法。本实施例主要以该方法应用于上述图1a中的业务服务器集群110中的业务服务器来举例说明。

参照图2，该请求量控制方法具体包括如下步骤：

S202，获取当前时间窗口的请求量信息。

其中，时间窗口是指对应有固定时间长度的时间区间或时间范围。固定时间长度可根据实际情况自定义，比如1分钟。时间窗口具体可包括多个时间片，每个时间片对应有时间长度，该多个时间片的时间长度总和等于时间窗口的固定时间长度。当前时间窗口是指当前时间所对应的时间窗口。请求量信息是用于描述或表征请求量的信息。可以理解，请求量信息中包括至少一个请求子量。

具体地，业务服务器集群中的每个业务服务器获取当前时间窗口内自身的请求量信息。在一个实施例中，业务服务器根据所接收到的业务请求动态更新本地缓存的请求量信息，并在进行请求量信息上报时，从本地获取缓存的当前时间窗口的请求量信息。

在一个实施例中，当满足请求量信息上报触发条件时，服务器确定当前时间窗口，并获取当前时间窗口的请求量信息。请求量信息上报触发条件是用于触发请求量信息上报操作的条件，比如检测到当前时间与预设的请求量信息上报触发时间一致，或者，自上一次上报请求量信息后达到指定时长，或者，接收到其他设备发送的请求量信息上报指令。

在一个实施例中，当前时间窗口包括多个第二时间片，每个第二时间片对应有请求子量。服务器确定当前时间窗口所包括的多个第二时间片，获取每个第二时间片对应的请求子量，并根据所获取到的请求子量得到当前时间窗口对应的请求量信息。

S204，根据请求量信息从额度分配服务器获得当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的请求量信息动态确定。

其中，当前请求量额度是指当前分配的请求量额度。请求量额度是指单位时间段内所允许响应或处理的业务请求的最大数量。单位时间段是指时间长度为单位时长的时间段，具体可以是指时间长度为单位时长的第一时间片，单位时长比如1秒。

具体地，业务服务器集群中的每个业务服务器将自身所获取到的当前时间窗口内的请求量信息上报至额度分配服务器。额度分配服务器根据所接收到的请求量信息对待分配的请求量总额度进行动态分配，以确定分配给每个业务服务器的当前请求量额度，并将所确定的当前请求量额度反馈至相应业务服务器。

在一个实施例中，额度分配服务器根据业务服务器集群中每个业务服务器上报的请求量信息，确定当前时间窗口内每个业务服务器分配的请求量占该业务服务器集群中的请求总量的比例，并基于所确定的比例和待分配的请求量总额度动态确定分配给相应业务服务器的当前请求量额度。

在一个实施例中，当前时间窗口包括多个第二时间片，每个第二时间片分别对应有请求子量。业务服务器将当前时间窗口内每个第二时间片的请求子量缓存在本地。业务服务器获取并上报至额度分配服务器的请求量信息，包括当前时间窗口内该多个第二时间片各自的请求子量。相应地，额度分配服务器基于各请求量信息中的多个请求子量对待分配的请求量总额度进行动态分配，并将各业务服务器上报的请求量信息缓存在本地。当业务服务器因通信失败而导致当前时间窗口的请求量信息未成功上报至额度分配服务器时，额度分配服务器仍然能够按照上一次上报并缓存的请求量信息进行请求量额度的动态分配。这样，由于网络问题造成业务服务器和额度分配服务器少量通信失败，不会对请求量额度分配的准确性产生影响，提高了容灾和容错能力，从而能够保证业务服务器对业务请求的有效响应或控制。

在一个实施例中，当前时间窗口包括多个第二时间片，请求量信息包括多个第二时间片各自的请求子量。额度分配服务器从每个业务服务器上报的请求量信息中，按照时序筛选靠前的部分第二时间片的请求子量，并根据筛选出的请求子量动态确定分配给每个业务服务器的当前请求量额度。由于请求量信息中按照时序靠后的一个或多个第二时间片的请求子量可能不准确，也就是该一个或多个第二时间片内的业务请求的数量可能统计不完整，由此，按照时序筛选较为准确的第二时间片的请求子量，并基于该较为准确的请求子量进行请求量额度的动态分配，能够提高当前请求量额度的准确性。

在一个实施例中，请求量信息中携带有业务标识。额度分配服务器从各业务服务器上报的请求量信息中筛选出相同业务标识对应的请求量信息，并基于筛选出的请求量信息和该业务标识对应的待分配的请求量总额度，动态确定分配给每个业务服务器的当前请求量额度。可以理解，当业务标识对应的待分配的请求量总额度大于或等于预设阈值时，额度分配服务器以业务为维度将该待分配的请求量总额度动态分配至各业务服务器。当业务标识对应的待分配的请求量总额度小于预设阈值时，额度分配服务器以业务服务器为维度，将请求量总额度小于预设阈值的多个业务标识各自的请求量总额度作为一个整体，动态分配至各业务服务器。

S206，在从获得当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在当前请求量额度内。

具体地，业务服务器在获得额度分配服务器基于所接收到的请求量信息动态分配的当前请求量额度后，在从获得该当前请求量额度起至下一次获得请求量额度止的时间段内，根据该当前请求量额度对每个第一时间片内的请求量进行控制，以将每个第一时间片内的请求量控制在该当前请求量额度内。

在一个实施例中，在从获得当前请求量额度起至下一次获得请求量额度止的时间段内，对于每个第一时间片，若第一时间片内的请求量小于当前请求量额度，业务服务器会对在该第一时间片内接收到的下一个业务请求进行处理或响应，并更新该第一时间片内的请求量；若第一时间片内的请求量大于或等于当前请求量额度，业务服务器则会拒绝处理或响应在该第一时间片内接收到的下一个业务请求，直至下一个第一时间片到来时继续处理或响应所接收到的业务请求。这样，将每个第一时间片内的请求量控制在相应的当前请求量额度内，能够避免业务服务器因请求量激增而雪崩或宕机的问题。

在一个实施例中，将每个第一时间片内的请求量控制在当前请求量额度内,包括：检测业务请求；当检测到业务请求时，获取当前第一时间片内的请求量；当请求量大于或等于当前请求量额度时，拒绝对业务请求的响应。

具体地，业务服务器实时检测业务请求，当检测到业务请求时，确定该业务请求所属的第一时间片作为当前第一时间片，获取该当前第一时间片内的请求量，并将所获取到的请求量与该当前第一时间片对应的当前请求量额度进行比较。当该当前第一时间片内的请求量大于或等于相应的当前请求量额度时，表明该当前第一时间片内的请求量超过所允许响应或处理的请求量，业务服务器则拒绝响应所接收到的业务请求。

在一个实施例中，当当前第一时间片内的请求量小于相应的当前请求量额度时，表明该第一时间片内的请求量处于正常请求量范围内，业务服务器则对所接收到的业务请求进行响应或处理。

在一个实施例中，业务服务器在接收到业务请求后，若判定自身的当前请求量额度为初始额度值，则直接对该业务请求进行处理或响应。初始额度值具体可以是0。由此，对于新增的业务服务器，在尚未采集到相应的请求量信息时，将初始额度值配置为该新增的业务服务器的当前请求量额度，并在后续采集到请求量信息时，基于所采集到的请求量信息动态进行当前请求量额度的分配。这样，在业务服务器集群中新增业务服务器时，也能较为准确的动态确定相应的当前请求量额度，以较为准确的进行请求量的控制。

在一个实施例中，当判定请求量大于或等于当前请求量额度时，业务服务器触发生成限额提示信息，并将所生成的限额提示信息反馈至发送相应业务请求的上游服务器。限额提示信息可用于提示上游服务器当前第一时间片内的请求量额度已使用完毕。可以理解，当拒绝响应所接收到的业务请求时，业务服务器则不会基于该业务请求调用下游服务器。

上述实施例中，基于动态分配的当前请求量额度和当前第一时间片内的请求量，确定在该当前第一时间片内接收到的业务请求的响应情况，由此实现对该当前第一时间片内的请求量的控制，从而能够实现对从获得当前请求量额度起至下一次获得请求量额度值的时间段内，每个第一时间片内的请求量的控制。

上述请求量控制方法，业务服务器集群中的每个业务服务器获取当前时间窗的请求量信息并上报至额度分配服务器，额度分配服务器基于该上报的请求量信息动态给每个业务服务器分配当前请求量额度。由此，各业务服务器的当前请求量额度是基于当前时间窗口对应的请求量信息自动动态分配的，无需人为干预，能够提高当前请求量额度分配的效率和准确性。业务服务器基于所分配的请求量额度，对当前时间后的一定时间段内每个时间片内的请求量进行控制，以避免业务服务器因负载过高而雪崩或宕机的问题。这样，基于当前时间窗口的请求量信息动态确定下一时间段内各时间片的请求量额度，并基于请求量额度进行请求量控制，能够提高请求量的控制效率。

在一个实施例中，当前时间窗口包括多个第二时间片；步骤S202包括：获取业务请求；根据业务请求的请求时间确定业务请求所属的第二时间片，更新所确定的第二时间片的请求子量；当满足请求量信息上报触发条件时，获取当前时间窗口内每个第二时间片的请求子量；根据请求子量得到当前时间窗口的请求量信息。

其中，第二时间片是具有特定时间长度的时间范围或时间区间。特定时间长度比如10秒。当前时间窗口包括多个第二时间片，当前时间窗口的时间长度等于该多个第二时间片各自的特定时间长度总和。业务请求是用于触发业务处理操作的请求。请求时间是业务请求对应的时间，具体可以是业务请求的生成时间或触发时间，也可以是业务请求的接收时间。可以理解，业务请求中可携带有业务标识和该业务请求的生成时间或触发时间。请求子量是指第二时间片内所接收到的业务请求的数量。

具体地，业务服务器获取业务请求，确定所获取到的业务请求的请求时间，根据请求时间确定该业务请求所属的第二时间片，并根据该业务请求更新其所属第二时间片的请求子量。业务服务器可解析所获取到的业务请求得到该业务请求的生成时间，作为该业务请求的请求时间。业务服务器也可将接收业务请求的接收时间作为该业务请求的请求时间。当满足请求量信息上报触发条件时，业务服务器确定当前时间窗口内的每个第二时间片，并获取每个第二时间片的请求子量。业务服务器根据所获取到的多个请求子量得到该当前时间窗口的请求量信息。

在一个实施例中，业务服务器实时检测当前时间和/或其他设备发送的请求量信息上报指令。当检测到当前时间与预设的请求量信息上报触发时间一致时，或者，当检测到请求量信息上报指令时，业务服务器判定满足请求量信息上报触发条件，则获取当前时间窗口内每个第二时间片的请求子量。

在一个实施例中，业务服务器实时检测自上一次上报请求量信息后的等待时长，并将检测到的等待时长与预设时长进行比较。当等待时长大于或等于预设时长时，业务服务器获取当前时间窗口内每个第二时间片的请求子量。可以理解，业务服务器实时检测距离上一次上报请求量信息的时间间隔是否达到预设时长，若达到预设时长则判定满足请求量信息上报触发条件，并获取当前时间窗口的请求量信息。业务服务器按照预设周期定期上报当前时间窗口的请求量信息，以按照预设周期定期从额度分配服务器获取动态分配的请求量额度，而不是实时请求额度分配服务器进行请求量额度的分配，这样即使额度分配服务器短暂时间段内不可访问也不会对业务服务器造成严重的冲击，从而降低了运营成本，且保障了业务服务器对业务请求的有效响应。

在一个实施例中，业务服务器在获取到当前时间窗口内每个第二时间片的请求子量后，将每个第二时间片的第二时间片标识与请求子量进行关联，并根据关联后的第二时间片标识和请求子量得到当前时间窗口的请求量信息。这样，请求量信息中包括当前时间窗口内各第二时间片标识和相应的请求子量。

在一个实施例中，业务服务器根据当前时间窗口内按照时序靠前的部分第二时间片的请求子量，得到该当前时间窗口的请求量信息。可以理解，业务服务器也可从当前时间窗口内筛选按照时序靠前的部分第二时间片，根据筛选出的第二时间片的第二时间片标识和请求子量得到当前时间窗口的请求量信息。

上述实施例中，按照时间片统计所接收到的业务请求的请求量，并在满足请求量信息上报触发条件时，按照时间片统计上报的请求子量，并根据按照时间片统计的请求子量得到当前时间窗口的请求量信息，作为待上报的请求量信息。这样，按照时间片统计请求子量，并按照时间窗口上报请求量信息，以从额度分配服务器获取当前请求量额度，在保证请求量额度的有效分配的情况下，减少了业务服务器与额度分配服务器的通信频率，能够有效避免因频繁通信而增加系统通信负载的问题，且能有提高系统的容灾和容错能力。

在一个实施例中，根据业务请求的请求时间确定业务请求所属的第二时间片，更新所确定的第二时间片的请求子量，包括：根据业务请求的请求时间确定业务请求所属的第二时间片对应的第二时间片标识；根据第二时间片标识和请求时间确定业务请求对应的目标请求时间；当目标请求时间与第二时间片标识对应的时间戳一致时，对第二时间片标识对应的请求子量进行增量更新。

其中，第二时间片标识用于唯一标识第二时间片，具体可以是第二时间片对应的编号。当前时间窗口包括多个第二时间片，每个第二时间片对应一个编号，该多个编号连续且互不相同。增量更新是指对请求子量进行增量或递增的更新处理。

具体地，业务服务器确定所获取到的业务请求的请求时间，根据该请求时间确定相应业务请求所对应的第二时间片标识，该第二时间片标识为业务请求所属的第二时间片所对应的第二时间片标识。业务服务器根据业务请求对应的第二时间片标识和请求时间，确定该业务请求所对应的目标请求时间，并将所确定的目标请求时间与第二时间片标识当前对应的时间戳进行比较。当目标请求时间与第二时间片标识对应的时间戳一致时，对该第二时间片标识对应的请求子量进行增量更新。

在一个实施例中，业务服务器根据业务请求的请求时间，按照第一预设映射关系确定该业务请求对应的第二时间片标识。第一预设映射关系比如：index＝(A％60)/10,其中，A为业务请求的请求时间，％表示取模或求余操作，/表示取整操作，index为业务请求对应的第二时间片标识，也可理解为业务请求所属的第二时间片的索引或编号，index的取值范围在[0,5]之间。可以理解，上述第一预设映射关系中，取整对象可根据时间窗口内的第二时间片的数量动态调整，比如，当时间窗口包括3个第二时间片时，可将第一预设映射关系中的取整对象由10修改为20。时间窗口内第二时间片的数量可通过权衡请求计数的统计误差和统计效率动态确定。

在一个实施例中，业务服务器根据业务请求的请求时间和所确定的第二时间片标识，按照第二预设映射关系确定该业务请求对应的目标请求时间。第二预设映射关系比如：timekey＝A-A％60+index*10，其中，A为业务请求的请求时间，timekey该业务请求的目标请求时间，index为按照上述第一预设映射关系确定的第二时间片标识。在本实施例中，以相同的基准时间为计时起点来计算各业务请求的请求时间，基准时间比如指定年份的起始时间，也可以是每个月、每周或每天的起始时间。

举例说明，假设以每天的起始时间为基准时间，某个业务请求的请求时间为5点12分，则按照第一预设映射关系index＝((5*60+12)％60)/10，可确定该业务请求对应的第二时间片标识为1，相应地，按照第二预设映射关系timekey＝(5*60+12)-(5*60+12)％60+1*10，可确定该业务请求对应的目标请求时间为310秒，就是5点10分。这样，请求时间为5点10分到5点19分的业务请求的所对应的目标请求时间均统一为5点10分，并将目标请求时间为5点10分的业务请求统计至时间戳为5点10分的第二时间片对应的请求子量内。

在一个实施例中，当目标请求时间与第二时间片标识对应的时间戳一致时，表明业务请求属于当前时间窗口内该第二时间片标识对应的第二时间片内，业务服务器将该第二时间片标识对应的请求子量加一得到更新后的请求子量，并将该第二时间片标识当前对应的请求子量更新为更新后的请求子量。这样，业务服务器在接收到下一个同属于该第二时间片的业务请求时，对该更新后的请求子量进行增量更新。

上述实施例中，根据业务请求的请求时间确定该业务请求对应的第二时间片标识，并根据第二时间片标识对请求时间进行处理得到相应的目标请求时间，以在业务请求属于当前时间窗口内的该第二时间片时，动态增量更新该第二时间片的请求子量。按照该种方式能够准确统计到各个第二时间片的请求子量。

在一个实施例中，根据业务请求的请求时间确定业务请求所属的第二时间片，更新所确定的第二时间片的请求子量，还包括：当目标请求时间与第二时间片标识对应的时间戳不一致时，将第二时间片标识对应的请求子量重置为请求子量初始统计值；将第二时间片标识对应的时间戳更新为目标请求时间。

其中，请求子量初始统计值是指第二时间片标识对应的请求子量的初始统计值。初始统计值是指进行请求子量统计时的初始值。可以理解，请求子量初始统计值是指对第二时间片内的业务请求进行初始统计时的请求子量取值。

具体地，当当前接收到的业务请求对应的目标请求时间与第二时间片标识对应的时间戳不一致时，表明时间窗口存在更新，也就是表明该当前接收到的业务请求与上一次接收到的业务请求分属于不同的时间窗口，业务服务器则将该当前接收到的业务请求对应的第二时间片标识所对应的请求子量重置为请求子量初始统计值。相应地，业务服务器将该业务请求对应的第二时间片标识所对应的时间戳重置为该业务请求对应的目标请求时间，也就是将该第二时间片标识对应的时间戳更新为相应的目标请求时间。

在一个实施例中，当所确定的目标请求时间与第二时间片标识对应的时间戳不一致时，表明时间窗口产生回轮，也就是表明在前一个时间窗口内时序最靠前的一个第二时间片成为当前时间窗口内时序最靠后的一个第二时间片。举例说明，假设每个时间窗口包括6个第二时间片，该6个第二时间片各自的第二时间片标识分别为0、1、2、3、4和5，若前一个时间窗口内该6个第二时间片的时序为0、1、2、3、4、5，则时间窗口产生回轮后，当前时间窗口内该6个第二时间片的时序为1、2、3、4、5、0。这样，当时间窗口产生回轮时，前一个时间窗口的第一个第二时间片标识成为当前时间窗口的最后一个第二时间片标识。

在一个实施例中，随着时间的推移，时间窗口的时间长度固定不变，每个时间窗口所包括的第二时间片的数量和第二时间片标识保持不变，但时间窗口内的多个第二时间片的时序或排序循环变化。由此，任意相邻两个时间窗口内第二时间片的时序不同，也就是任意相邻两个时间窗口内第二时间片标识的排序不同。可以理解，若业务服务器相邻两次上报请求量信息的时间间隔小于第二时间片的时间长度，则相邻两次上报的请求量信息所对应的当前时间窗口可能为同一个时间窗口。

图3为一个实施例中时间窗口的结构示意图。如图3所示，时间窗口包括6个时间长度一致的第二时间片，该6个第二时间片各自的第二时间标识分别为0、1、2、3、4和5，且该6个第二时间片以首尾相连的方式进行顺序拼接得到相应的时间窗口。每个第二时间片对应有时间，对每个第二时间片内的业务请求进行计数得到相应的请求子量，由此，每个时间片对应有时间和请求计数两个维度的信息。图3所示为饼状的时间窗口，按照时序依次对时间窗口内的每个第二时间片进行请求计数，当依次进行的请求计数执行完毕时，时间窗口会产生回轮，继续执行按照时序依次对时间窗口内的每个第二时间片进行请求计数的步骤。时间窗口内的每个时间片可理解为一个内存格子，多个内存格子构成完整的内存结构。业务服务器在接收到业务请求后，根据该业务请求的请求时间确定该业务请求所属的内存格子，并更新该内存格子的请求计数，也就是更新第二时间片的请求子量。

值得说明的是，图3中所示的时间窗口的时间长度为1分钟，将时间窗口分为6个时间片，每个时间片的时间长度为10秒，仅仅作为示例，并不用于限定时间窗口的时间长度，以及时间窗口所包括的时间片数量。

图4为另一个实施例中时间窗口的结构示意图。图4与图3所示的时间窗口相对应，图4所示为链状的时间窗口，能够直观表征时间窗口的回轮，以及相邻两个时间窗口内各第二时间片的时序。图4的虚线框内的多个第二时间片构成当前时间窗口，随着时间的推移，时间窗口按照每次一个第二时间片的步长往前滑动，形成新的时间窗口，由此，通过不断滑动时间窗口能够形成如图4所示的链状结构。第二时间标识可理解为第二时间片的索引。当当前时间窗口内索引4对应的第二时间片内的业务请求统计完毕时，该当前时间窗口会产生回轮，下一个时间窗口内会对索引5对应的第二时间片内的业务请求进行重新统计，依此类推，能够不断更新时间窗口内各第二时间片的时序和请求子量。

在一个实施例中，业务服务器对应于时间窗口分配一个长度为6的数组，该数组的每项对应一个第二时间片，该数组的每项为一个包括时间和请求计数的结构体，时间为第二时间片对应的时间，请求计数为第二时间片的请求子量。

上述实施例中，当基于所接收到的业务请求判定时间窗口产生回轮，则将该业务请求所属的第二时间片的请求子量重置为请求子量初始统计值，以及将该第二时间片的时间戳重置为业务请求对应的目标请求时间，这样在回轮后的时间窗口内基于重置的请求子量初始统计值和时间戳，重新对该第二时间片进行请求计数。

在一个实施例中，请求量信息与进程标识对应；步骤S204包括：将自身运行的进程数和每个进程标识对应的请求量信息上报至额度分配服务器；接收额度分配服务器对应于进程标识反馈的当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的进程数，以及每个进程标识对应的请求量信息动态确定。

其中，进程标识用于唯一标识进程。进程是运行于业务服务器中且能够实现业务逻辑的服务或程序。一个业务服务器中运行有至少一个进程，业务服务器通过进程响应或处理所接收到的业务请求。

具体地，业务服务器通过自身运行的进程响应或处理所接收到的业务请求，并按照进程分别统计当前时间窗口内的每个第二时间片的请求子量，也就是统计每个进程在当前时间窗口内的每个第二时间片的请求子量。可以理解，该第二时间片的请求子量用于表征相应进程在该第二时间片内的请求量分布，包括已响应的业务请求和拒绝响应的业务请求，还可包括待响应的业务请求。当满足请求量信息上报触发条件时，业务服务器根据自身运行的每个进程的进程标识，获取每个进程在当前时间窗口内的每个第二时间片的请求子量，并根据所获取到的请求子量得到每个进程在当前时间窗口内的请求量信息。业务服务器统计自身运行的进程数，并将统计的进程数和每个进程在当前时间窗口内的请求量信息上报至额度分配服务器。

额度分配服务器根据业务服务器集群中每个业务服务器上报的进程数和每个进程对应的请求量信息对待分配的请求量总额度进行动态分配，以动态确定分配至每个业务服务器上的每个进程的当前请求量额度，并将所确定的当前请求量额度反馈至相应的业务服务器。相应地，业务服务器接收额度服务器针对自身运行的每个进程动态分配的当前请求量额度，并在从获得当前请求量额度至下一次获得请求量额度的时间段内，通过每个进程将该进程在每个第一时间片内的请求量控制在相应的当前请求量额度内。

在一个实施例中，在从获得分配给每个进程的当前请求量额度起至下一次获得请求量额度止的时间段内，业务服务器通过自身运行的每个进程实时检测分配该进程的业务请求。当检测到业务请求时，业务服务器通过检测到该业务请求的进程获取该进程在当前第一时间片内的请求量，并将所获取到的请求量与该进程对应的当前请求量额度进行比较。当判定请求量大于或等于相应当前请求量额度时，业务服务器通过该进程拒绝对所检测到的业务请求的响应。

上述实施例中，按照进程上报当前时间窗口内的请求量信息，以在进程维度上进行请求量额度的动态分配，能够提高请求量额度分配的准确性。这样，基于所分配的当前请求量额度能够实现进程维度上的请求量控制，从而能够提高请求量控制的准确性。

在一个实施例中，接收额度分配服务器对应于进程标识反馈的当前请求量额度，包括：接收额度分配服务器对应于进程标识反馈的当前请求量额度，以及业务服务器集群中运行的进程总数；当在接收到当前请求量额度后达到预设时长时，未接收到额度分配服务器下一次反馈的请求量额度，根据进程总数和待分配的请求量总额度确定分配给自身运行的每个进程的请求量额度。

其中，进程总数是指业务服务器集群中各个业务服务器上所运行的进程的总数量。预设时长是预先设定的用于判定额度分配服务器的运行情况的时间长度，可自定义，比如5分钟。

具体地，额度分配服务器根据各业务服务器上报的进程数和每个进程的请求量信息，动态确定分配给每个进程的当前请求量额度，以及业务服务器集群中运行的进程总数后，将分配给每个进程的当前请求量额度和业务服务器集群中运行的进程总数反馈至相应的业务服务器。业务服务器将所接收到的进程总数缓存在本地，并将每个进程的请求量控制在相应的当前请求量额度内。业务服务器在接收到动态分配的当前请求量额度后，实时检测额度分配服务器下一次动态分配的请求量额度，并统计下一次请求量额度分配的等待时长。当统计的等待时长大于或等于预设时长时，业务服务器仍然未接收到额度分配服务器下一次分配的请求量额度，则判定额度分配服务器运行异常，业务服务器则根据缓存的进程总数和待分配的请求量总额度，自动确定分配给自身运行的每个进程的请求量额度。

在一个实施例中，当判定额度分配服务器运行异常时，业务服务器根据进程总数和待分配的请求量总额度确定平均请求量额度，并将该平均请求量额度确定为自身运行的每个进程的当前请求量额度。这样，即使在额度分配服务器运行异常时也能够实现请求量额度的分配，进而基于分配的请求量额度进行请求量的控制，提高了业务服务器及该业务服务器所处系统的容灾和容错能力。

在一个实施例中，业务服务器接收管理设备同步至的待分配的请求量总额度，并缓存在本地，以在判定额度分配服务器运行异常时，能够基于缓存的请求量总额度实现请求量额度的自行分配。可以理解，管理设备可基于用户的触发操作实现待分配的请求量总额度的配置。管理设备具体可以是管理终端或管理服务器。

在一个实施例中，在接收到额度分配服务器动态分配的当前请求量额度后，业务服务器检测额度分配服务器下一次动态分配的请求量额度，并在未检测到该下一次动态分配的请求量额度时，保持该当前请求量额度不变，并基于该当前请求量额度进行请求量控制，直至检测到下一次动态分配的请求量额度，或者，统计到等待时长大于或等于预设时长时，基于重新确定的请求量额度进行请求量控制。这样，在未接收到额度分配服务器下一次动态分配的请求量额度、且等待市场未超过预设时长时，则判定由于网络问题导致未成功接收到下一次分配的请求量额度，并基于当前请求量额度进行请求量控制，能够提高业务服务器的容错能力。

上述实施例中，将分配给每个进程的当前请求量额度与业务服务器集群中的进程总数一并反馈至业务服务器，以在预设时长内未接收到动态分配的请求量额度时基于进程总数实现请求量额度的自行分配，以提高容灾和容错能力。

如图5所示，提供了一种请求量控制方法，将该方法应用于业务服务器集群中的业务服务器进行举例说明，该方法具体包括以下步骤：

S502，获取业务请求。

S504，根据业务请求的请求时间确定业务请求所属的第二时间片对应的第二时间片标识。

S506，根据第二时间片标识和请求时间确定业务请求对应的目标请求时间。

S508，当目标请求时间与第二时间片标识对应的时间戳一致时，对第二时间片标识对应的请求子量进行增量更新。

S510，当目标请求时间与第二时间片标识对应的时间戳不一致时，将第二时间片标识对应的请求子量重置为请求子量初始统计值。

S512，将第二时间片标识对应的时间戳更新为目标请求时间。

S514，当满足请求量信息上报触发条件时，获取当前时间窗口内每个第二时间片的请求子量。

S516，根据请求子量得到当前时间窗口的请求量信息。

S518，根据请求量信息从额度分配服务器获得当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的请求量信息动态确定。

S520，在从获得当前请求量额度起至下一次获得请求量额度止的时间段内，检测业务请求。

S522，当检测到业务请求时，获取当前第一时间片内的请求量。

S524，当请求量大于或等于当前请求量额度时，拒绝对业务请求的响应。

上述实施例中，根据业务请求的请求时间对每个第二时间片进行请求计数得到请求子量，当满足请求量信息上报触发条件时，按照当前时间窗口上报由多个第二时间片的请求子量得到的请求量信息，以根据上报的请求量信息得到动态分配的当前请求量额度，在减少业务服务器与额度分配服务器的通信频次的情况下，能够保证请求量额度的有效分配，且上报包括多个第二时间片的请求子量的请求量信息能够提高业务服务器所在系统的容灾和容错能力，从而能够保证请求量额度的分配准确性和效率。进一步地，基于动态分配的当前请求量额度进行请求量控制能够提高请求量的控制效率和准确性，从而能够有效避免因负载过重导致业务服务器雪崩或宕机的问题。

如图6所示，在一个实施例中，提供了一种请求量控制方法，将该方法应用于额度分配服务器进行举例说明，该方法包括以下步骤：

S602，接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息。

具体地，业务服务器集群中的每个业务服务器获取自身在当前时间窗口的请求量信息，并将所获取到的请求量信息上报至额度分配服务器。额度分配服务器接收业务服务器集群中的每个业务服务器分别上报的当前时间窗口内的请求量信息。

在一个实施例中，业务服务器集群在接收到业务请求时，根据业务请求的请求时间确定该业务请求所属的第二时间片，并根据该业务请求更新其所属第二时间片的请求子量。当满足请求量信息上报触发条件时，业务服务器获取当前时间窗口内每个第二时间片的请求子量，根据多个第二时间片的请求子量得到该当前时间窗口的请求量信息，并将该请求量信息上报至额度分配服务器。

在一个实施例中，额度分配服务器接收每个业务服务器上报的、且包括当前时间窗口内按照时序靠前的部分第二时间片的请求子量的请求量信息，以便于基于该按照时序靠前的部分第二时间片的请求子量进行请求量额度分配，得到更为准确的当前请求量额度。

在一个实施例中，额度分配服务器接收每个业务服务器按照进程上报的当前时间窗口的请求量信息，以便于根据每个进程的请求量信息动态确定分配给每个进程的当前请求量额度，能够提高请求量额度分配的精准度，在按照进程进行请求量控制时能够提高请求量控制的准确性。

在一个实施例中，额度分配服务器接收每个业务服务器上报的自身运行的进程数和每个进程在当前时间窗口对应的请求量信息。

S604，根据请求量信息和待分配的请求量总额度动态确定分配给每个业务服务器的当前请求量额度。

具体地，额度分配服务器根据业务服务器集群中每个业务服务器上报的当前时间窗口的请求量信息，确定每个业务服务器在当前时间窗口内的请求量占该业务服务器集群中的请求量的比例，并根据所确定的比例和待分配的请求量总额度动态确定分配给每个业务服务器的当前请求量额度。

在一个实施例中，当前时间窗口包括多个第二时间片，每个第二时间片对应有请求子量。当前时间窗口的请求量信息包括多个第二时间片各自的请求子量。额度分配服务器根据所接收到的每个请求量信息中的多个请求子量，得到相应业务服务器在当前时间窗口对应的第一请求总量，根据每个业务服务器的第一请求总量得到业务服务器集群的在当前时间窗口对应的第二请求总量，并根据第一请求总量和第二请求总量得到相应业务服务器在业务服务器集群中所占的请求量比例。

在一个实施例中，额度分配服务器根据当前时间窗口内每个第二时间片的请求子量，或者，根据当前时间窗口内按照时序靠前的部分第二时间片的请求子量，得到相应业务服务器在该当前时间窗口对应的第一请求总量。相应地，额度分配服务器根据请求量信息中的每个请求子量，或者，根据请求量信息中按照时序靠前的部分第二时间片的请求子量，得到相应业务服务器在当前时间窗口对应的第一请求总量。

在一个实施例中，当接收到业务服务器按照进程上报的请求量信息时，额度分配服务器根据每个进程在当前时间窗口的请求量信息，以及待分配的请求量总额度动态确定分配给每个进程的当前请求量额度。

在一个实施例中，额度分配服务器根据所接收到的当前时间窗口的请求量信息，按照业务将待分配的请求量总额度动态分配至每个进程。可以理解，当业务标识对应的待分配的请求量总额度大于或等于预设阈值时，额度分配服务器将该业务标识对应的请求量总额度按照上述方式进行动态分配。当业务标识对应的待分配的请求量总额度小于预设阈值时，多个请求量总额度小于预设阈值的业务标识各自的请求量总额度作为一个整体进行动态分配。

在一个实施例中，在请求量额度的动态分配过程中，额度分配服务器本地或通过网络通信从管理设备获取待分配的请求量总额度。额度分配服务器本地的待分配的请求量总额度是由管理设备预先同步并缓存在本地的请求量总额度，能够减少额度分配服务器与管理设备的通信次数，也能够避免因网络问题无法实时获取请求量总额度时而影响请求量额度的动态分配的问题。

S606，将当前请求量额度反馈至相应的业务服务器；反馈的当前请求量额度用于指示相应的业务服务器基于当前请求量额度进行请求量控制。

具体地，额度分配服务器按照业务服务器集群中各业务服务器上报的请求量信息，动态确定分配给每个业务服务器的当前请求量额度后，将所确定的当前请求量额度反馈至相应的业务服务器。业务服务器在接收到额度分配服务器针对上报的请求量信息反馈的当前请求量额度时，在从获得当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在当前请求量额度内，以实现对每个第一时间片内的请求量的控制。

在一个实施例中，额度分配服务器将动态确定的当前请求量额度和业务服务器集群中业务服务器的数量反馈至相应业务服务器，以便于业务服务器在额度分配服务器运行异常时，能够基于待分配的请求量总额度和业务服务器的数量进行请求量额度的自行分配，能够提高容灾和容错能力。

在一个实施例中，额度分配服务器将分配给每个进程的当前请求量额度和业务服务器集群中的进程总数反馈至相应业务服务器，以便于业务服务器在判定额度分配服务器运行异常时自动确定分配给每个进程的当前请求量额度。

上述请求量控制方法，额度分配服务器接收业务服务器集群中每个业务服务器分别上报的当前时间窗口的请求量信息，并基于该上报的请求量信息和待分配的请求量总额度动态给每个业务服务器分配当前请求量额度，由此基于当前时间窗口的请求量信息自动动态分配当前请求量额度，而无需人工干预，能够提高请求量额度的分配效率。额度分配服务器将自动分配的当前请求量额度反馈至各业务服务器，以使得各业务服务器基于所分配的当前请求量额度进行请求量控制，从而能够提高请求量的控制效率。

在一个实施例中，当前时间窗口包括多个第二时间片；每个第二时间片与请求子量对应；步骤S604包括：从请求量信息中选取按照时序靠前的部分第二时间片的请求子量；根据选取的请求子量得到相应业务服务器所对应的第一请求总量；根据每个业务服务器对应的第一请求总量得到业务服务器集群所对应的第二请求总量；根据第一请求总量、第二请求总量和待分配的请求量总额度，动态确定分配给相应业务服务器的当前请求量额度。

具体地，当前时间窗口包括多个第二时间片，每个第二时间片对应有请求子量。相应地，业务服务器上报的当前时间窗口的请求量信息包括多个第二时间片各自的请求子量。额度分配服务器从所接收到的每个请求量信息中，按照时序选取靠前的部分第二时间片的请求子量，根据所选取出的请求子量得到相应请求量信息所对应的第一请求总量，并将该第一请求总量确定为相应业务服务器所对应的第一请求总量。额度分配服务器根据业务服务器集群中每个业务服务器对应的第一请求总量，得到该业务服务器集群对应的第二请求总量。额度分配服务器根据每个业务服务器对应的第一请求总量、业务服务器集群对应的第二请求总量和待分配的请求量总额度，动态确定分配给相应业务服务器的当前请求量额度。

在一个实施例中，在进行请求量信息上报时，当前时间窗口内按照时序靠前后第二时间片内的请求计数可能不完整，额度分配服务器从请求量信息中选取按照时序靠前的部分第二时间片的请求子量进行请求量额度的动态分配，以保证所计算的第二时间片内的请求技术的完整性，从而保证请求量额度分配的准确性。这样，按照各业务服务器的正常请求量分配比例动态确定每个业务服务器的当前请求量额度，以便于在请求量激增时，能够基于动态分配的当前请求量额度进行请求量控制。

在一个实施例中，额度分配服务器从请求量信息中按照时序选取靠前的部分第二时间片的请求子量，并基于所选取的请求子量进行请求量额度的动态分配。在此，所选取的部分第二时间片的请求子量不做具体限定。例如，可选取按照时序靠前的4个第二时间片的请求子量，也可选取距离当前时间15秒之前的第二时间片的请求子量。

上述实施例中，从上报的请求量信息中选取准确性较高的部分请求子量进行请求量额度的动态分配，能够提高当前请求量额度的准确性，以便于业务服务器基于该准确性较高的当前请求量额度进行请求量控制时，能够提高请求量控制的准确性。

在一个实施例中，业务服务器集群为区块链网络；业务服务器为区块链网络中的区块链节点服务器；步骤S604包括：获取每个区块链节点服务器的历史上报信息；从区块链网络中筛选历史上报信息符合正常运行判定条件的目标区块链节点服务器；根据目标区块链节点服务器上报的请求量信息和待分配的请求量总额度动态确定分配给每个目标区块链节点服务器的当前请求量额度。

其中，历史上报信息是指当前时间之前上报的历史记录信息，具体可用于表征当前时间之前请求量信息的上报情况。历史上报信息中记录有当前时间之前业务服务器每次上报请求量信息的上报时间。正常运行判定条件是用于判定业务服务器是否处于正常运行状态的判定条件或依据。正常运行判定条件比如，业务服务器最近第一预设时长内有请求量信息上报记录，和/或，业务服务器稳定上报请求量信息的时长大于或等于第二预设时长。第一预设时长比如15秒，第二预设时长比如2分钟。业务服务器集群为区块链网络，业务服务器集群中的每个业务服务器为区块链网络中的区块链节点服务器。

具体地，额度分配服务器在获取到区块链节点服务器上报的请求量信息后，从本地获取每个区块链节点服务器的历史上报信息。额度分配服务器将所获取到的历史上报信息与预设的正常运行判定条件进行比较，以根据比较结果从区块链网络中筛选历史上报信息符合正常运行判定条件的目标区块链节点服务器，也就是从区块链网络中筛选历史上报信息符合正常运行判定条件的区块链节点服务器作为目标区块链节点服务器。额度分配服务器根据筛选出的目标区块链节点服务器上报的请求量信息，以及待分配的请求量总额度按照上述方式进行请求量额度的动态分配，以确定分配给每个目标区块链节点服务器的当前请求量额度。

在一个实施例中，额度分配服务器和业务服务器在进行数据交互时建立心跳机制，以基于所建立测心跳机制判断数据交互对象的运作情况。

在一个实施例中，当业务服务器集群中新增业务服务器时，额度分配服务器将该新增业务服务器上报的请求量信息设定为默认值，并基于该默认值和其他业务服务器上报的请求量信息进行请求量额度的动态分配。可以理解，对于新增的业务服务器，在初始运行的部分第一时间片内可不进行请求量控制，或者，按照初始请求量额度进行请求量控制。当采集到多个第二时间片的请求子量时，再基于该多个第二时间片的请求子量进行请求量额度的动态分配。

在一个实施例中，额度分配服务器对每个业务服务器的历史上报信息进行分析，以确定每个业务服务器的请求量信息上报统计情况。当请求量信息上报统计情况不符合正常运行判定条件时，则判定相应业务服务器运行异常，则不再按照上述方式动态给该运行异常的业务服务器分配当前请求量额度。

在一个实施例中，若当前未接收到业务服务器集群中的一个或多个业务服务器上报的请求量信息时，额度分配服务器可基于其他业务服务器成功上报的请求量信息，以及该一个或多个业务服务器前次成功上报的请求量信息进行请求量额度的动态分配，以保证请求量额度的分配效率。这样，当由于网络问题未成功接收到业务服务器上报的请求量信息时，仍然可以进行请求量额度的分配，只要该业务服务器在下一次或者下下次能够成功上报自身的请求量信息即可，由此能够提高容灾和容错的能力。

在一个实施例中，当存在未成功上报请求量信息的业务服务器时，额度分配服务器可保持该业务服务器的当前请求量额度不变，并基于成功上报的请求量信息对其他业务服务器的当前请求量额度进行动态分配。

上述实施例中，基于历史上报信息判定各业务服务器的运行情况，并对运行正常的业务服务器进行请求量额度的动态分配，以提高请求量额度分配的准确性。

在一个实施例中，在一些特殊的时间节点，瞬间会有巨大请求量涌向包括业务服务器的后台系统，对后台系统造成巨大的冲击。其中，请求量也可理解为流量。这些瞬间流量通常是预估峰值流量的7至8倍。异常情况可能触发几十倍的流量涌入，可能对业务服务器等后台服务器甚至后台系统造成巨大的冲击。但是，通常情况下不会给每个业务服务器分配过多的资源或额度，即使分配有足够的资源或额度，在峰值过后，业务服务器的资源利用率比较低，造成了资源浪费。其次，部分流量本身是冗余或无效流量，由此对上游进行流量控制，也就是对请求量进行控制是至关重要的。

目前，通常基于静态分配方式给每个业务服务器分配固定的请求量额度，或者，基于业务请求实时请求各业务服务器的请求量额度。基于静态分配方式给每个业务服务器分配固定的请求量额度，容易实现，且对业务处理逻辑影响较小，但是运营复杂，容灾能力弱。尤其是在包括不同机型的业务服务器的异构环境下很难确定每个业务服务器的请求量额度，其次，当业务服务器异常需要下线或需要新增业务服务器时，需要人为干预重新进行请求量额度的分配，且操作复杂，降低了请求量额度的分配效率，从而降低了容灾能力。

基于业务请求实时请求相应请求量额度的方式中，请求量总额度存储于额度分配服务器，业务服务器在接收到每个业务请求后，都要基于所接收到的业务请求在额度分配服务器中查询是否存在剩余的请求量额度，若存在，则响应该业务请求。该种分配方式需要频繁从额度分配服务器中查询当前剩余的请求量额度，增加了操作复杂度和成本，且容灾能力差，尤其是在额度分配服务器运行异常时会导致业务请求的响应阻塞，可能对整个业务产生风险。其次，在流量暴增时，需要对额度分配服务器进行扩容，增加了运营成本和复杂度。

而本申请提供的请求量控制方法，业务服务器按照第二时间片进行请求计数，按照时间窗口将多个第二时间片的请求子量缓存在本地，以在满足请求量信息上报触发条件时，业务服务器根据缓存的请求子量得到当前时间窗口的请求量信息，并将该请求量信息自动上报至额度分配服务器。额度分配服务器基于所接收到的请求量信息和待分配的请求量总额度进行请求量额度的动态分配，并将动态确定的请求量额度反馈至业务服务器。这样，基于正常情况下的请求量分布动态确定请求量突增异常情况下各业务服务器的请求量分布/请求量额度。业务服务器将每个第一时间片内的请求量控制在相应的当前请求量额度内，以在流量正常时尽量减少请求量控制对业务正常处理逻辑的影响，请求量异常时能够基于分配的请求量额度实现请求量的精准控制。

应该理解的是，虽然本申请各实施例的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，各实施例中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

如图7所示，在一个实施例中，提供了一种请求量控制系统，该系统包括：业务服务器集群110、额度分配服务器120和路由服务器130。其中，业务服务器集群110至少包括业务服务器112和业务服务器114。处理服务器集群110中的每个业务服务器，通过网络分别与额度分配服务器120和路由服务器130进行通信。路由服务器130可理解为业务服务器集群110的上游服务器，将待处理的业务请求路由至业务服务器集群110中的任一业务服务器进行响应或处理。业务服务器集群110中的每个业务服务器，按照第二时间片进行请求计数，并按照时间窗口将当前时间窗口内每个第二时间片的请求子量缓存在本地，以在满足请求量信息上报触发条件时，根据缓存的多个请求子量得到当前时间窗口的请求量信息，并将该请求量信息上报至额度分配服务器，以指示额度分配服务器基于该上报的请求量信息进行请求量额度的动态分配。

在一个实施例中，若业务服务器通过自身运行的进程对所接收到的业务请求进行响应或处理，则会针对每个进程分别统计当前时间窗口的请求量信息，并将每个进程的请求量信息上报至额度分配服务器。可以理解，业务服务器可将自身运行的多个进程各自的请求量信息一并上报至额度分配服务器，也可以将每个进程各自的请求量信息分别上报至额度分配服务器。

如图8所示，在另一个实施例中，提供了一种请求量控制系统，该系统包括：业务服务器集群110、额度分配服务器120、路由服务器130、管理设备140和处理服务器集群150。其中，处理服务器集群150至少包括处理服务器152和处理服务器154。处理服务器集群110中的每个业务服务器，通过网络分别与额度分配服务器120、路由服务器130、管理设备140和处理服务器集群150进行通信。处理服务器集群150中的处理业务服务器可理解为业务服务器集群110的下游服务器，基于业务服务器的调用进行相应的业务处理。

业务服务器集群110中的每个业务服务器可调用处理服务器集群150中的任意一个处理服务器。管理设备140可基于用户的触发操作完成各项配置，并将配置同步至业务服务器集群110中的各个业务服务器。例如。管理设备140可将针对每个业务标识配置的待分配的请求量总额度同步至每个业务服务器。可以理解，管理设备140可将待分配的请求量总额度通过网络直接同步至额度分配服务器120，也可通过业务服务器同步至额度分配服务器120。

在一个实施例中，上述请求量控制方法基于较少的资源进行请求量控制，以保证业务服务器集群110和/或处理服务器集群150等后台服务器，在用户请求量突然爆发性涌入时能够安全运行，且在实践中方便运营和管理。上述请求量控制方法可广泛应用于各种秒杀活动，或者，应用于各种请求量或流量不可预测突发情况的客户端游戏活动中。

如图9所示，在又一个实施例中，提供了一种请求量控制系统，该系统包括：业务服务器集群110、额度分配服务器120、路由服务器130和代理服务器集群160。其中，代理服务器集群160至少包括代理服务器162和代理服务器164。代理服务器集群160中的每个代理服务器与业务服务器集群110中的每个业务服务器一一对应，且相互之间通过网络进行通信。

代理服务器中存储相应业务服务器在当前时间窗口内每个第二时间片的请求子量，以及额度分配服务器针对上报的请求量信息动态分配的当前请求量额度。业务服务器在接收到业务请求时，通过代理服务器判断当前第一时间片的请求量是否大于或等于当前请求量额度，并根据判断结果对该业务请求进行相应的处理，以实现请求量的控制。相应地，业务服务器将所接收到的业务请求和/或业务请求的请求时间发送至代理服务器，以指示代理服务器对该业务请求所属的第二时间片进行请求计数。代理服务器按照预设周期定期向额度分配服务器上报当前时间窗口的请求量信息，以从额度分配服务器获取相应业务服务器的当前请求量额度。这样，将业务处理逻辑与请求量控制逻辑进行分别部署，能够降低业务服务器的数据处理压力。

可以理解，当业务服务器通过自身运行的一个或多个进程对业务请求进行响应或处理是，也可通过代理服务器按照上述请求量控制逻辑进行请求量控制。

在一个实施例中，业务服务器集群110中的多个业务服务器可通过同一个代理服务器进行请求量控制。

在一个实施例中，可在图7或图8所示的业务服务器集群110中的每个业务服务器中部署代理服务和业务服务，业务服务器通过业务服务处理或相应业务请求，通过该代理服务器对自身的请求量进行控制。代理服务可理解为部署于业务服务器、且能够实现上述代理服务器的相关功能的服务。业务处理和代理服务可理解为运行业务服务器中的不同进程。活动服务与代理服务可通过共享内存或unix套接字的方式进行通信，以提高通信效率。业务服务与代理服务可进行实时通信，也可按照指定周期进行定期通信。相应地，代理服务与额度分配服务器可进行实时通信，也可按照指定周期进行定期通信。这样，基于进程间的通信实现请求量控制，能够提高通信效率，从而提高请求量的控制效率。基于该种方式能够较为灵活的实现请求量的控制。

如图10所示，在一个实施例中，提供了一种请求量控制装置1000，该装置包括：获取模块1002、分配模块1004和控制模块1006，其中，

获取模块1002，用于获取当前时间窗口的请求量信息。

分配模块1004，用于根据请求量信息从额度分配服务器获得当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的请求量信息动态确定。

控制模块1006，用于在从获得当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在当前请求量额度内。

在一个实施例中，当前时间窗口包括多个第二时间片；获取模块1002，还用于获取业务请求；根据业务请求的请求时间确定业务请求所属的第二时间片，更新所确定的第二时间片的请求子量；当满足请求量信息上报触发条件时，获取当前时间窗口内每个第二时间片的请求子量；根据请求子量得到当前时间窗口的请求量信息。

在一个实施例中，获取模块1002，还用于根据业务请求的请求时间确定业务请求所属的第二时间片对应的第二时间片标识；根据第二时间片标识和请求时间确定业务请求对应的目标请求时间；当目标请求时间与第二时间片标识对应的时间戳一致时，对第二时间片标识对应的请求子量进行增量更新。

在一个实施例中，获取模块1002，还用于当目标请求时间与第二时间片标识对应的时间戳不一致时，将第二时间片标识对应的请求子量重置为请求子量初始统计值；将第二时间片标识对应的时间戳更新为目标请求时间。

在一个实施例中，请求量信息与进程标识对应；分配模块1004，还用于将自身运行的进程数和每个进程标识对应的请求量信息上报至额度分配服务器；接收额度分配服务器对应于进程标识反馈的当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的进程数，以及每个进程标识对应的请求量信息动态确定。

在一个实施例中，分配模块1004，还用于接收额度分配服务器对应于进程标识反馈的当前请求量额度，以及业务服务器集群中运行的进程总数；当在接收到当前请求量额度后达到预设时长时，未接收到额度分配服务器下一次反馈的请求量额度，根据进程总数和待分配的请求量总额度确定分配给自身运行的每个进程的请求量额度。

在一个实施例中，控制模块1006，还用于检测业务请求；当检测到业务请求时，获取当前第一时间片内的请求量；当请求量大于或等于当前请求量额度时，拒绝对业务请求的响应。

如图11所示，在一个实施例中，提供了一种请求量控制装置1100，该装置包括：接收模块1102、分配模块1104和反馈模块1106，其中：

接收模块1102，用于接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息。

分配模块1104，用于根据请求量信息和待分配的请求量总额度动态确定分配给每个业务服务器的当前请求量额度。

反馈模块1106，用于将当前请求量额度反馈至相应的业务服务器；反馈的当前请求量额度用于指示相应的业务服务器基于当前请求量额度进行请求量控制。

在一个实施例中，当前时间窗口包括多个第二时间片；每个第二时间片与请求子量对应；分配模块1104，还用于从请求量信息中选取按照时序靠前的部分第二时间片的请求子量；根据选取的请求子量得到相应业务服务器所对应的第一请求总量；根据每个业务服务器对应的第一请求总量得到业务服务器集群所对应的第二请求总量；根据第一请求总量、第二请求总量和待分配的请求量总额度，动态确定分配给相应业务服务器的当前请求量额度。

在一个实施例中，业务服务器集群为区块链网络；业务服务器为区块链网络中的区块链节点服务器；分配模块1104，还用于获取每个区块链节点服务器的历史上报信息；从区块链网络中筛选历史上报信息符合正常运行判定条件的目标区块链节点服务器；根据目标区块链节点服务器上报的请求量信息和待分配的请求量总额度动态确定分配给每个目标区块链节点服务器的当前请求量额度。

图12示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是图1中的业务服务器集群110中的业务服务器，或者，额度分配服务器120。如图12所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现请求量控制方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行请求量控制方法。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，本申请提供的请求量控制装置可以实现为一种计算机程序的形式，计算机程序可在如图12所示的计算机设备上运行。计算机设备的存储器中可存储组成该请求量控制装置的各个程序模块。比如，图10所示的获取模块1002、分配模块1004和控制模块1006。各个程序模块构成的计算机程序使得处理器执行本说明书中描述的本申请各个实施例的请求量控制方法中的步骤。还比如，比如，图11所示的接收模块1102、分配模块1104和反馈模块1106。各个程序模块构成的计算机程序使得处理器执行本说明书中描述的本申请各个实施例的请求量控制方法中的步骤。

例如，图12所示的计算机设备可以通过如图10所示的请求量控制装置中的获取模块1002执行步骤S202。计算机设备可通过分配模块1004执行步骤S204。计算机设备可通过控制模块1006执行步骤S206。

例如，图12所示的计算机设备可以通过如图11所示的请求量控制装置中的接收模块1102执行步骤S602。计算机设备可通过分配模块1104执行步骤S604。计算机设备可通过反馈模块1106执行步骤S606。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述请求量控制方法的步骤。此处请求量控制方法的步骤可以是上述各个实施例的请求量控制方法中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述请求量控制方法的步骤。此处请求量控制方法的步骤可以是上述各个实施例的请求量控制方法中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (22)

1.一种请求量控制方法，应用于业务服务器集群中的业务服务器，所述方法包括：

获取当前时间窗口的请求量信息；

根据所述请求量信息从额度分配服务器获得当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的请求量信息动态确定，所述当前请求量额度是指当前分配的请求量额度，所述请求量额度指单位时间段内所允许响应或处理的业务请求的最大数量；

在从获得所述当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在所述当前请求量额度内。

2.根据权利要求1所述的方法，其特征在于，所述当前时间窗口包括多个第二时间片；所述获取当前时间窗口的请求量信息，包括：

获取业务请求；

根据所述业务请求的请求时间确定所述业务请求所属的第二时间片，更新所确定的所述第二时间片的请求子量；

当满足请求量信息上报触发条件时，获取当前时间窗口内每个第二时间片的请求子量；

根据所述请求子量得到所述当前时间窗口的请求量信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述业务请求的请求时间确定所述业务请求所属的第二时间片，更新所确定的所述第二时间片的请求子量，包括：

根据所述业务请求的请求时间确定所述业务请求所属的第二时间片对应的第二时间片标识；

根据所述第二时间片标识和所述请求时间确定所述业务请求对应的目标请求时间；

当所述目标请求时间与所述第二时间片标识对应的时间戳一致时，对所述第二时间片标识对应的请求子量进行增量更新。

4.根据权利要求3所述的方法，其特征在于，所述根据所述业务请求的请求时间确定所述业务请求所属的第二时间片，更新所确定的所述第二时间片的请求子量，还包括：

当所述目标请求时间与所述第二时间片标识对应的时间戳不一致时，将所述第二时间片标识对应的请求子量重置为请求子量初始统计值；

将所述第二时间片标识对应的时间戳更新为所述目标请求时间。

5.根据权利要求1所述的方法，其特征在于，所述请求量信息与进程标识对应；所述根据所述请求量信息从额度分配服务器获得当前请求量额度，包括：

将自身运行的进程数和每个进程标识对应的请求量信息上报至额度分配服务器；

接收所述额度分配服务器对应于所述进程标识反馈的当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的进程数，以及每个进程标识对应的请求量信息动态确定。

6.根据权利要求5所述的方法，其特征在于，所述接收所述额度分配服务器对应于所述进程标识反馈的当前请求量额度，包括：

接收所述额度分配服务器对应于所述进程标识反馈的当前请求量额度，以及所述业务服务器集群中运行的进程总数；

当在接收到所述当前请求量额度后达到预设时长时，未接收到所述额度分配服务器下一次反馈的请求量额度，根据所述进程总数和待分配的请求量总额度确定分配给自身运行的每个进程的请求量额度。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述将每个第一时间片内的请求量控制在所述当前请求量额度内,包括：

检测业务请求；

当检测到所述业务请求时，获取当前第一时间片内的请求量；

当所述请求量大于或等于所述当前请求量额度时，拒绝对所述业务请求的响应。

8.一种请求量控制方法，应用于额度分配服务器，所述方法包括：

接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息；

根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度，所述当前请求量额度是指当前分配的请求量额度，所述请求量额度指单位时间段内所允许响应或处理的业务请求的最大数量；

将所述当前请求量额度反馈至相应的业务服务器；反馈的所述当前请求量额度用于指示相应的业务服务器基于所述当前请求量额度进行请求量控制。

9.根据权利要求8所述的方法，其特征在于，所述当前时间窗口包括多个第二时间片；每个所述第二时间片与请求子量对应；所述根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度，包括：

从所述请求量信息中选取按照时序靠前的部分第二时间片的请求子量；

根据选取的所述请求子量得到相应业务服务器所对应的第一请求总量；

根据每个所述业务服务器对应的第一请求总量得到所述业务服务器集群所对应的第二请求总量；

根据所述第一请求总量、所述第二请求总量和所述待分配的请求量总额度，动态确定分配给相应业务服务器的当前请求量额度。

10.根据权利要求8所述的方法，其特征在于，所述业务服务器集群为区块链网络；所述业务服务器为所述区块链网络中的区块链节点服务器；所述根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度，包括：

获取所述每个区块链节点服务器的历史上报信息；

从所述区块链网络中筛选历史上报信息符合正常运行判定条件的目标区块链节点服务器；

根据所述目标区块链节点服务器上报的请求量信息和待分配的请求量总额度动态确定分配给每个目标区块链节点服务器的当前请求量额度。

11.一种请求量控制装置，其特征在于，所述装置设置于业务服务器集群中的业务服务器，所述装置包括：

获取模块，用于获取当前时间窗口的请求量信息；

分配模块，用于根据所述请求量信息从额度分配服务器获得当前请求量额度；所述当前请求量额度由所述额度分配服务器根据所述业务服务器集群中的每个业务服务器上报的请求量信息动态确定，所述当前请求量额度是指当前分配的请求量额度，所述请求量额度指单位时间段内所允许响应或处理的业务请求的最大数量；

控制模块，用于在从获得所述当前请求量额度起至下一次获得请求量额度止的时间段内，将每个第一时间片内的请求量控制在所述当前请求量额度内。

12.根据权利要求11所述的装置，其特征在于，所述当前时间窗口包括多个第二时间片；

所述获取模块，还用于获取业务请求；根据业务请求的请求时间确定业务请求所属的第二时间片，更新所确定的第二时间片的请求子量；当满足请求量信息上报触发条件时，获取当前时间窗口内每个第二时间片的请求子量；根据请求子量得到当前时间窗口的请求量信息。

13.根据权利要求12所述的装置，其特征在于，所述获取模块，还用于根据业务请求的请求时间确定业务请求所属的第二时间片对应的第二时间片标识；根据第二时间片标识和请求时间确定业务请求对应的目标请求时间；当目标请求时间与第二时间片标识对应的时间戳一致时，对第二时间片标识对应的请求子量进行增量更新。

14.根据权利要求13所述的装置，其特征在于，所述获取模块，还用于当目标请求时间与第二时间片标识对应的时间戳不一致时，将第二时间片标识对应的请求子量重置为请求子量初始统计值；将第二时间片标识对应的时间戳更新为目标请求时间。

15.根据权利要求11所述的装置，其特征在于，所述请求量信息与进程标识对应；

所述分配模块，还用于将自身运行的进程数和每个进程标识对应的请求量信息上报至额度分配服务器；接收额度分配服务器对应于进程标识反馈的当前请求量额度；当前请求量额度由额度分配服务器根据业务服务器集群中的每个业务服务器上报的进程数，以及每个进程标识对应的请求量信息动态确定。

16.根据权利要求15所述的装置，其特征在于，所述分配模块，还用于接收额度分配服务器对应于进程标识反馈的当前请求量额度，以及业务服务器集群中运行的进程总数；当在接收到当前请求量额度后达到预设时长时，未接收到额度分配服务器下一次反馈的请求量额度，根据进程总数和待分配的请求量总额度确定分配给自身运行的每个进程的请求量额度。

17.根据权利要求11至16任意一项所述的装置，其特征在于，所述控制模块，还用于检测业务请求；当检测到业务请求时，获取当前第一时间片内的请求量；当请求量大于或等于当前请求量额度时，拒绝对业务请求的响应。

18.一种请求量控制装置，其特征在于，所述装置设置于额度分配服务器，所述装置包括：

接收模块，用于接收业务服务器集群中每个业务服务器获取并上报的当前时间窗口的请求量信息；

分配模块，用于根据所述请求量信息和待分配的请求量总额度动态确定分配给所述每个业务服务器的当前请求量额度，所述当前请求量额度是指当前分配的请求量额度，所述请求量额度指单位时间段内所允许响应或处理的业务请求的最大数量；

反馈模块，用于将所述当前请求量额度反馈至相应的业务服务器；反馈的所述当前请求量额度用于指示相应的业务服务器基于所述当前请求量额度进行请求量控制。

19.根据权利要求18所述的装置，其特征在于，所述当前时间窗口包括多个第二时间片；每个所述第二时间片与请求子量对应；

所述分配模块，还用于从请求量信息中选取按照时序靠前的部分第二时间片的请求子量；根据选取的请求子量得到相应业务服务器所对应的第一请求总量；根据每个业务服务器对应的第一请求总量得到业务服务器集群所对应的第二请求总量；根据第一请求总量、第二请求总量和待分配的请求量总额度，动态确定分配给相应业务服务器的当前请求量额度。

20.根据权利要求18所述的装置，其特征在于，所述业务服务器集群为区块链网络；所述业务服务器为区块链网络中的区块链节点服务器；

所述分配模块，还用于获取每个区块链节点服务器的历史上报信息；从区块链网络中筛选历史上报信息符合正常运行判定条件的目标区块链节点服务器；根据目标区块链节点服务器上报的请求量信息和待分配的请求量总额度动态确定分配给每个目标区块链节点服务器的当前请求量额度。

21.一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行如权利要求1至10中任一项所述方法的步骤。

22.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行如权利要求1至10中任一项所述方法的步骤。

Images