CN113422736A - 基于令牌桶的请求管理方法、装置、设备及程序产品 - Google Patents

Abstract

本发明公开了一种基于令牌桶的请求管理方法、装置、设备及程序产品，属于通信领域。本发明中，方法包括以下步骤：接收到请求信息时，从第一令牌桶提取令牌；其中，所述第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，所述第一令牌桶内令牌的数量等于第一预设值；若提取到令牌，响应所述请求信息执行相应操作。本发明中，令牌的数量不受到令牌填充速率的影响，从而在不超过TPS的情况下，提高令牌桶响应请求的速率。

Description

基于令牌桶的请求管理方法、装置、设备及程序产品

技术领域

本发明涉及通信领域，尤其涉及一种基于令牌桶的请求管理方法、装置、设备及程序产品。

背景技术

相关技术中，高并发情况下大量数据通过网关进入系统，导致系统负载压力过大，需要高效的流量限制服务来解决。令牌桶技术(Token Bucket)是一种常见的流量测量技术，常用于流量的限制和流量的整形，能够对流量的速率和突发进行测量。

但是令牌桶技术中面对持续时长较长的高并发流量时，请求难以及时从令牌桶提取到令牌。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种基于令牌桶的请求管理方法、装置、设备及程序产品，旨在解决在持续时长较长的高并发流量时，请求难以及时从令牌桶提取到令牌的技术问题。

为实现上述目的，第一方面，本发明提供一种基于令牌桶的请求管理方法，包括以下步骤：

接收到请求信息时，从第一令牌桶提取令牌；其中，所述第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，所述第一令牌桶内令牌的数量等于第一预设值；

若提取到令牌，响应所述请求信息执行相应操作。

在一实施例中，所述接收到请求信息时，从第一令牌桶提取令牌的步骤之前，所述方法还包括：

接收请求信息，并根据接收到所述请求信息的时间数据，计算出消息接收间隔；

若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌；其中，所述第二令牌桶根据预设速率填充令牌；

所述接收到请求信息时，从第一令牌桶提取令牌的步骤，包括：

若所述消息接收间隔小于或者等于预设阈值，从第一令牌桶提取令牌。

在一实施例中，所述根据接收到所述请求信息的时间数据，计算出消息接收间隔的步骤包括：

根据接收到所述请求信息的时间数据，计算得到所述请求信息与上一请求信息的当前消息接收间隔；

根据所述当前消息接收间隔、前预设数量个历史请求信息的平均消息接收间隔、第一个历史请求信息和第二个历史请求信息的第一消息接收间隔和预设公式，获得所述消息接收间隔；

其中，所述预设公式为：

其中，AVE为所述消息接收间隔，T_average为平均消息接收间隔，n为历史请求信息的数量，T₁为所述第一消息接收间隔，T_in为所述当前消息接收间隔。

在一实施例中，所述若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌的步骤之后，所述方法还包括：

若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度；其中，所述缓冲队列与所述第二令牌桶相关联；

若所述缓冲队列未达到所述额定最大长度，将所述请求信息保存至缓冲队列中；

在满足触发条件时，将所述请求信息取出，并返回至若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌的步骤。

在一实施例中，所述若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度的步骤之后，所述方法还包括：

若所述缓冲队列达到所述额定最大长度，拒绝所述请求信息。

在一实施例中，所述若所述消息接收间隔大于预设阈值，从第一令牌桶提取令牌的步骤之后，所述方法还包括：

若没有提取到令牌，拒绝所述请求信息。

在一实施例中，所述接收到请求信息时，从第一令牌桶提取令牌的步骤之前，所述方法还包括：

监听系统管理平台的消息队列的变更信息，其中，所述变更信息包括所述第一预设值、所述消息接收间隔和/或所述预设速率的更新信息；

基于所述变更信息，更新所述第一预设值、所述消息接收间隔和/或所述预设速率。

第二方面，本发明还提供了一种基于令牌桶的请求管理装置，包括：

令牌提取模块，用于接收到请求信息时，从第一令牌桶提取令牌；其中，所述第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，所述第一令牌桶内令牌的数量等于第一预设值；

请求响应模块，用于若提取到令牌，响应所述请求信息执行相应操作。

第三方面，本发明还提供了一种基于令牌桶的请求管理设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的基于令牌桶的请求管理程序，所述基于令牌桶的请求管理配置为实现如上述的基于令牌桶的请求管理方法的步骤。

第四方面，本发明还提供了一种计算机程序产品，包括可执行的程序代码，其中，所述程序代码在由处理器执行时执行如上述的基于令牌桶的请求管理方法。

本发明技术方案通过将第一令牌桶设置为每个预设周期开始时均进行初始化，以使任一预设周期开始时，第一令牌桶内令牌的数量等于第一预设值，确保任一预设周期内，令牌的数量不受到令牌填充速率的影响，从而在不超过TPS的情况下，提高令牌桶响应请求的速率。

附图说明

图1为本发明一种基于令牌桶的请求管理方法的推荐电子设备的结构示意图；

图2为本发明一种基于令牌桶的请求管理方法第一实施例的流程示意图；

图3为本发明一种基于令牌桶的请求管理方法第二实施例的流程示意图；

图4为本发明一种基于令牌桶的请求管理方法第三实施例的流程示意图；

图5为本发明一种基于令牌桶的请求管理装置的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

相关技术中，诸如商品秒杀系统、能力开放API(Application ProgrammingInterface，应用程序接口)等在产品设计、开发以及商用阶段往往都需要应对高并发请求。面对高并发请求，无论是为了防止大量的请求导致服务器过载，还是为了满足来自业务需求在应用级、接口级、用户级的每秒事务处理量TPS限制，需要高效的流量限制服务来解决。

其中，常见的限流方案包括计数器算法、漏桶算法以及令牌桶算法。计数器算法实现简单，占用资源少，但是存在“突刺现象”。漏桶算法消除了“突刺现象”，但是无法兼容瞬时突发流量。在令牌桶算法中，需要设置两个参数：桶最大容量cap(流量突发增多时可以调用的token令牌数)和token令牌的生成速率rate。令牌生成节点或者令牌生成器会按恒定1/TPS秒往令牌桶里填充token，如果令牌桶已经满了就不再加了。每次请求调用需要先从令牌桶内提取令牌，只有提取到令牌，该请求调用才能够继续执行，否则选择等待可用的令牌或者拒绝相应该请求调用。请求调用提取令牌后，令牌桶内令牌的数量减少。但是令牌桶算法在面对持续时间较长的高并发请求时，令牌桶的填充速率难以匹配TPS限制下的令牌消耗数量，导致系统的每秒事务处理量未能充分发挥，存在请求等待令牌填充的情况。

为此，本发明提供了一种基于令牌桶的请求管理方法，该请求管理方法通过将第一令牌桶设置为每个预设周期开始时均执行初始化或者其他更新操作，以使任一预设周期开始时，第一令牌桶内令牌的数量等于第一预设值，确保任一预设周期内，令牌的数量不受到令牌填充速率的影响，从而在不超过TPS的情况下，提高请求响应的速率。

本发明提供一种基于令牌桶的请求管理方法第一实施例中。参阅图2，图2为本发明基于令牌桶的请求管理方法第一实施例的流程示意图。

本实施例中，基于令牌桶的请求管理方法包括以下步骤：

步骤S101、接收到请求信息时，从第一令牌桶提取令牌。其中，第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，第一令牌桶内令牌的数量等于第一预设值。

第一令牌桶的容量恒定，即第一令牌桶内的令牌数量始终不超过第一预设值。不同于现有令牌桶根据预设速率填充令牌，本实施例中，第一令牌桶在每个预设周期开始时会对第一令牌桶进行更新。更新操作可以是对第一令牌桶进行初始化。初始化操作可为消耗上一预设周期内剩下的令牌，并根据计数器一次性填充第一预设值个令牌。此时，第一令牌桶内的令牌只在一个预设周期内有效。计数器将预设周期内的令牌数量限制在第一预设值内。

或者，更新操作还可以是根据第一令牌桶内剩余令牌的数量进行补充，使得第一令牌桶内令牌总量重新达到第一预设值。可以理解的，第一预设值与系统的TPS相关，以确保接收相应数量的请求信息后，系统不过载。此处的系统可以是一服务节点。

从而本实施例中，每个预设周期开始，第一令牌桶内始终具有最大数量个令牌，相较于令牌按照预设速率进行填充，本实施例可以满足持续高并发请求信息所需，以减少请求信息等待的时间，更好地响应请求信息，进而提高系统的在满足TPS限制下的处理事务能力。

更新完成后，预设周期内剩余时间不再填充令牌，即使预设周期内第一令牌桶内令牌被消耗一空，也不会填充新的令牌。

还需说明的是，预设周期可以是单位时间，即第一令牌桶在每个单位时间开始时更新，一次性填充第一预设值个令牌。然后在下一单位时间再次更新。

步骤S102、若提取到令牌，响应请求信息执行相应操作。

本实施例中，请求信息可为相应的请求报文，在接收到请求报文后，需要从第一令牌桶提取并消耗相应数量的令牌。在第一令牌桶中令牌的数量足够时，请求信息可从第一令牌桶中提取并消耗足够的令牌，此时，该请求信息方可被响应，如请求信息为用户的API调用请求，在提取到足够数量的令牌时，该API调用请求被响应，用户可调用相应的API。或者，该请求信息为请求报文，在提取到足够数量的令牌时，该请求报文被发送至目标服务器中。

步骤S103、若没有提取到令牌，拒绝请求信息。

在没有获取到足够数量的令牌时，该请求信息被拒绝或者被丢弃。

本实施例中，通过将第一令牌桶的令牌填充设置为一次性填充，确保任一预设周期内，令牌的数量不受到令牌填充速率的影响，从而在不超过TPS的情况下，提高请求响应的速率。

在本发明的基于令牌桶的请求管理方法第一实施例的基础上，提出本发明的基于令牌桶的请求管理方法第二实施例。参阅图3，图3为本发明基于令牌桶的请求管理方法第二实施例的流程示意图。

本实施例中，方法包括以下步骤：

步骤S201、接收请求信息，并根据接收到请求信息的时间数据，计算出消息接收间隔；

该步骤中，可通过请求统计器统计接收到请求信息的时间戳，进而根据时间戳计算得到消息接收间隔，从而判断出请求信息是否构成高并发请求信息。

具体而言，步骤S201包括：

步骤A10、根据接收到请求信息的时间数据，计算得到请求信息与上一请求信息的当前消息接收间隔。

步骤A20、根据当前消息接收间隔、前预设数量个历史请求信息的平均消息接收间隔、第一个历史请求信息和第二个历史请求信息的第一消息接收间隔和预设公式，获得消息接收间隔。

具体而言，请求统计器内预置有四个参数：最新请求进来的时间lastestTime，上一请求信息进来的时间nextToLastTime、第一个历史请求信息和第二个历史请求信息进来的时间相减得到的消息接收间隔T₁、前预设数量个历史请求信息的平均消息接收间隔T_average。

当接收到请求信息时，更新lastestTime和nextToLastTime的值。并计算得到当前消息接收间隔T_in，T_in＝nextToLastTime-lastestTime。

然后根据预设公式

计算得到消息接收间隔。

其中，AVE为消息接收间隔，T_average为平均消息接收间隔，n为历史请求信息的数量，T₁为第一消息接收间隔，T_in为当前消息接收间隔。

该消息接收间隔通过平均消息接收间隔和当前消息接收间隔加权计算，得到最近n个请求信息的消息接收间隔，可以较为准确地反映出最近n个请求信息是否构成高并发请求。

步骤S202、若消息接收间隔大于预设阈值，从第二令牌桶提取令牌。其中，第二令牌桶根据预设速率填充令牌。

若该消息接收间隔大于预设阈值，说明此时系统的流量未达到高并发标准，因此，此时，可从第二令牌桶提取令牌。

第二令牌桶根据预设速率填充令牌。第二令牌桶可具有两个参数，即桶最大容量cap(流量突发增多时可以调用的token令牌数)和token令牌的生成速率rate。为了区分第一令牌桶和第二令牌桶，第二令牌桶可为单令牌桶。单令牌桶生成器每1/TPS秒生成一个token令牌填充至第二令牌桶中。请求信息进来则提取token进行消费。没有请求进来，token存活1/TPS秒之后自动销毁，以确保第二令牌桶内始终仅仅只有一个令牌。

本实施例中，通过第二令牌桶处理普通的请求信息，以避免在常规状态下，使用第一令牌桶徒占系统资源。

其中，单令牌桶生成器可包括N个。N的具体数值根据系统的TPS而变化。如对于平台级TPS，系统可包括第一等级令牌车间，第一等级令牌车间包括N1个单令牌桶生成器。且系统根据生成器类型、生成器容积率flowRate为第一等级令牌车间划分资源。此时，第一等级令牌车间占用资源最多，相对容积率更小。

对于用户级TPS，系统可包括第二等级令牌车间，第二等级令牌车间包括N2个单令牌桶生成器，N2＜N1。且系统根据生成器类型、生成器容积率flowRate为第二等级令牌车间划分资源。此时，第二等级令牌车间占用资源减少，相对容积率稍高。

对于接口级TPS，系统可包括第三等级令牌车间，第三等级令牌车间包括N3个单令牌桶生成器，N3＜N2。且系统根据生成器类型、生成器容积率flowRate为第三等级令牌车间划分资源。此时，第三等级令牌车间占用资源最少，相对容积率最高。

本实施例中，针对平台级、用户级或者接口级TPS，采用不同等级令牌车间生成令牌，从而确保系统的TPS不溢出。

步骤S203、若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度。其中，缓冲队列与第二令牌桶相关联。

步骤S204、若缓冲队列未达到额定最大长度，将请求信息保存至缓冲队列中。

步骤S205、在满足触发条件时，将请求信息取出，并返回至步骤S202。

缓冲队列为一队列缓冲器，如可基于rocketmq实现。缓冲队列未达到额定最大长度时，可将未提取到令牌的请求信息发送至缓冲队列中。如此可避免令牌刚失效，新的请求信息进来，因获取不到令牌而被拒绝。

请求信息在缓冲队列内保存至满足触发条件时，将请求信息取出，并再此尝试从第二令牌桶中提取令牌。触发条件可以是请求信息保存了预设时间，或者系统一段时间内未接收到请求信息时，该触发条件可根据具体情况具体设置，本实施例在此不再赘述。

步骤S206、若缓冲队列达到额定最大长度，拒绝请求信息。

若缓冲队列达到额定最大长度，即缓冲队列已满，则直接拒绝该请求信息，以对服务节点或者系统的流量进行限制。

步骤S207、若消息接收间隔小于或者等于预设阈值，从第一令牌桶提取令牌。

若该消息接收间隔小于或者等于预设阈值，说明此时系统的流量达到高并发标准，因此，此时，可从第一令牌桶提取令牌。通过第一令牌桶满足高并发时的流量所需。

步骤S208、若没有提取到令牌，拒绝请求信息。

本实施例中，基于第一令牌桶和第二令牌桶进行双桶限流，在常规流量时，通过第一令牌桶限制流量，而在高并发流量时，通过第二令牌桶限制流量，从而同时解决了现有限流技术的“突刺现象”、允许突发流量的问题。并通过第一令牌桶的第一预设值解决了现有令牌桶技术的TPS溢出的问题。

相关技术中，令牌桶的最大容量cap(流量突发增多时可以调用的token令牌数)和token令牌的生成速率rate等参数布置在redis数据结构服务器上。而redis数据结构服务器为分布式集群。管理员通过分布式集群的管理服务器更新上述的令牌桶的最大容量cap(流量突发增多时可以调用的token令牌数)和token令牌的生成速率rate等参数。但是分布式集群的节点难以在管理服务器更新后及时更新节点自身的令牌桶的最大容量cap(流量突发增多时可以调用的token令牌数)和token令牌的生成速率rate等参数。

因此，在本发明的基于令牌桶的请求管理方法第一实施例和第二实施例的基础上，提出本发明的基于令牌桶的请求管理方法第三实施例。参阅图4，图4为本发明基于令牌桶的请求管理方法第三实施例的流程示意图。

本实施例中，在步骤S101或者步骤S201之前，方法还包括以下步骤：

步骤S10、监听系统管理平台的消息队列的变更信息，变更信息包括第一预设值、消息接收间隔和/或预设速率的更新信息。

步骤S20、基于变更信息，更新第一预设值、消息接收间隔和/或预设速率。

本实施例中，在管理员在网页端通过分布式集群的管理服务器更新第一预设值、消息接收间隔和/或预设速率等参数后。管理服务器将前述的更新信息保存至消息队列中。

系统，即服务节点的令牌生成器监听消息队列，将第一预设值、消息接收间隔和/或预设速率的最新参数刷新至服务节点的本地内存中，从而及时更新参数。

此外，参阅图5，本发明还提供了一种基于令牌桶的请求管理装置，包括：

令牌提取模块10，用于接收到请求信息时，从第一令牌桶提取令牌；其中，第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，第一令牌桶内令牌的数量等于第一预设值；

请求响应模块20，用于若提取到令牌，响应请求信息执行相应操作。

在一实施例中，基于令牌桶的请求管理装置还包括：

请求接收模块，用于接收请求信息，并根据接收到所述请求信息的时间数据，计算出消息接收间隔；

第二令牌提取模块，用于若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌；其中，所述第二令牌桶根据预设速率填充令牌；

令牌提取模块10还用于若所述消息接收间隔小于或者等于预设阈值，从第一令牌桶提取令牌。

在一实施例中，请求接收模块包括：

当前消息接收间隔计算单元，用于根据接收到所述请求信息的时间数据，计算得到所述请求信息与上一请求信息的当前消息接收间隔；

消息接收间隔计算单元，用于根据所述当前消息接收间隔、前预设数量个历史请求信息的平均消息接收间隔、第一个历史请求信息和第二个历史请求信息的第一消息接收间隔和预设公式，获得所述消息接收间隔；

其中，所述预设公式为：

其中，AVE为所述消息接收间隔，T_average为所述平均消息接收间隔，n为历史请求信息的数量，T₁为所述第一消息接收间隔，T_in为所述当前消息接收间隔。

在一实施例中，基于令牌桶的请求管理装置还包括：

队列长度判断模块，用于若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度；其中，所述缓冲队列与所述第二令牌桶相关联；

队列保存模块，用于若所述缓冲队列未达到所述额定最大长度，将所述请求信息保存至所述缓冲队列中；

消息取出模块，用于在满足触发条件时，将所述请求信息取出，并返回至若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌的步骤。

在一实施例中，请求响应模块20，还用于若所述缓冲队列达到所述额定最大长度，拒绝所述请求信息。

在一实施例中，请求响应模块20，还用于若没有提取到令牌，拒绝所述请求信息。

在一实施例中，基于令牌桶的请求管理装置还包括：

监听模块，用于监听系统管理平台的消息队列的变更信息，其中，所述变更信息包括所述第一预设值、所述消息接收间隔和/或所述预设速率的更新信息；

参数变更模块，用于基于所述变更信息，更新所述第一预设值、所述消息接收间隔和/或所述预设速率。

参照图1，图1为本发明实施例方案涉及的一种基于令牌桶的请求管理方法的推荐电子设备的结构示意图。

该基于令牌桶的请求管理设备包括：至少一个处理器301、存储器302以及存储在存储器上并可在处理器上运行的基于令牌桶的请求管理程序，基于令牌桶的请求管理程序配置为实现如前的基于令牌桶的请求管理方法的步骤。

处理器301可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器301可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器301也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(CentralProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器301可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。

存储器302可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器302还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器302中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器301所执行以实现本申请中方法实施例提供的基于令牌桶的请求管理方法。

基于令牌桶的请求管理设备还包括有：通信接口303。处理器301、存储器302和通信接口303之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与通信接口303相连。

通信接口303可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器301和存储器302。在一些实施例中，处理器301、存储器302和通信接口303被集成在同一芯片或电路板上；在一些其他实施例中，处理器301、存储器302和通信接口303中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

本领域技术人员可以理解，图1中示出的结构并不构成对基于令牌桶的请求管理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

此外，本发明实施例还提出一种计算机程序产品，计算机程序产上存储有基于令牌桶的请求管理程序，基于令牌桶的请求管理程序被处理器执行时实现如上文的基于令牌桶的请求管理方法的步骤。因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品实施例中未披露的技术细节，请参照本申请方法实施例的描述。确定为示例，程序指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种基于令牌桶的请求管理方法，其特征在于，包括以下步骤：

接收到请求信息时，从第一令牌桶提取令牌；其中，所述第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，所述第一令牌桶内令牌的数量等于第一预设值；

若提取到令牌，响应所述请求信息执行相应操作。

2.根据权利要求1所述的基于令牌桶的请求管理方法，其特征在于，所述接收到请求信息时，从第一令牌桶提取令牌的步骤之前，所述方法还包括：

接收请求信息，并根据接收到所述请求信息的时间数据，计算出消息接收间隔；

若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌；其中，所述第二令牌桶根据预设速率填充令牌；

所述接收到请求信息时，从第一令牌桶提取令牌的步骤，包括：

若所述消息接收间隔小于或者等于预设阈值，从第一令牌桶提取令牌。

3.根据权利要求2所述的基于令牌桶的请求管理方法，其特征在于，所述根据接收到所述请求信息的时间数据，计算出消息接收间隔的步骤包括：

根据接收到所述请求信息的时间数据，计算得到所述请求信息与上一请求信息的当前消息接收间隔；

根据所述当前消息接收间隔、前预设数量个历史请求信息的平均消息接收间隔、第一个历史请求信息和第二个历史请求信息的第一消息接收间隔和预设公式，获得所述消息接收间隔；

其中，所述预设公式为：

其中，AVE为所述消息接收间隔，T_average为所述平均消息接收间隔，n为历史请求信息的数量，T₁为所述第一消息接收间隔，T_in为所述当前消息接收间隔。

4.根据权利要求2所述的基于令牌桶的请求管理方法，其特征在于，所述若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌的步骤之后，所述方法还包括：

若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度；其中，所述缓冲队列与所述第二令牌桶相关联；

若所述缓冲队列未达到所述额定最大长度，将所述请求信息保存至所述缓冲队列中；

在满足触发条件时，将所述请求信息取出，并返回至若所述消息接收间隔大于预设阈值，从第二令牌桶提取令牌的步骤。

5.根据权利要求4所述的基于令牌桶的请求管理方法，其特征在于，所述若没有提取到令牌，判断缓冲队列的长度是否达到额定最大长度的步骤之后，所述方法还包括：

若所述缓冲队列达到所述额定最大长度，拒绝所述请求信息。

6.根据权利要求2所述的基于令牌桶的请求管理方法，其特征在于，所述若所述消息接收间隔大于预设阈值，从第一令牌桶提取令牌的步骤之后，所述方法还包括：

若没有提取到令牌，拒绝所述请求信息。

7.根据权利要求2所述的基于令牌桶的请求管理方法，其特征在于，所述接收到请求信息时，从第一令牌桶提取令牌的步骤之前，所述方法还包括：

监听系统管理平台的消息队列的变更信息，其中，所述变更信息包括所述第一预设值、所述消息接收间隔和/或所述预设速率的更新信息；

基于所述变更信息，更新所述第一预设值、所述消息接收间隔和/或所述预设速率。

8.一种基于令牌桶的请求管理装置，其特征在于，包括：

令牌提取模块，用于接收到请求信息时，从第一令牌桶提取令牌；其中，所述第一令牌桶根据预设周期进行更新，以使进入当前预设周期时，所述第一令牌桶内令牌的数量等于第一预设值；

请求响应模块，用于若提取到令牌，响应所述请求信息执行相应操作。

9.一种基于令牌桶的请求管理设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的基于令牌桶的请求管理程序，所述基于令牌桶的请求管理配置为实现如权利要求1至7中任一项所述的基于令牌桶的请求管理方法的步骤。

10.一种计算机程序产品，其特征在于，包括可执行的程序代码，其中，所述程序代码在由处理器执行时执行如权利要求1至7任一项所述的基于令牌桶的请求管理方法。

Images