CN116132371A - 限流方法、装置、设备、介质及产品 - Google Patents

Abstract

本申请提供了一种限流方法、装置、设备、介质及产品，通过根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，其中，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；随后向令牌桶中添加目标数量的令牌；然后在接收到第一用户请求的情况下，从令牌桶中获取令牌；随后在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；然后在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。本申请实施例能够解决在用户请求过多的情况下，无法处理用户请求的问题。

Description

限流方法、装置、设备、介质及产品

技术领域

本申请涉及数据网络技术领域，特别是涉及一种限流方法、装置、设备、介质及产品。

背景技术

随着互联网技术的发展，网络服务的应用越来越普遍，然而，在现有的数据网络中，由于报文流量的突发性，常常会导致网络拥塞，在大流量高并发系统中，一般通过缓存、限流和降级来控制流量。其中，限流是指限制到达系统的并发请求数，即单位时间内到达系统的请求数，使得系统能够正常的处理部分用户的请求，来保证系统的稳定性。

然而，现有技术中，通常通过多路复用的限流方式，将请求压入缓存队列，运用多条路对请求进行处理。但是在高负载场景下，这个时候每条路无法及时处理请求，用户进行大量重试，导致队列中的内容取出时很多都已经失效，无法响应用户请求。

发明内容

本申请提供的一种限流方法、装置、设备、介质及产品，能够解决用户请求过多的情况下，无法处理用户请求的问题。

第一方面，本申请实施例提供一种限流方法，方法包括：

根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；

向令牌桶中添加目标数量的令牌；

在接收到第一用户请求的情况下，从令牌桶中获取令牌；

在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；

在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。

第二方面，本申请提供一种限流装置，该装置包括：

第一确定模块，用于根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；

添加模块，用于向令牌桶中添加目标数量的令牌；

第一获取模块，用于在接收到第一用户请求的情况下，从令牌桶中获取令牌；

第一处理模块，用于在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；

第二处理模块，用于在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：处理器以及存储有计算机程序指令的存储器；

处理器执行计算机程序指令时实现如第一方面中任意一个实施例中的限流方法。

第四方面，本申请实施例提供了一种计算机存储介质，计算机存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面中任意一个实施例中的限流方法。

第五方面，本申请实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行实现如上述第一方面中任意一个实施例中的限流方法。

在本申请实施例提供的一种限流方法、装置、设备、介质及产品中，通过根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，其中，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；随后向令牌桶中添加目标数量的令牌；然后在接收到第一用户请求的情况下，从令牌桶中获取令牌；随后在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；然后在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。通过上述方式，能够通过每次添加令牌的时间，确定每次接收用户请求时添加的令牌数量，即在每次接收用户请求时，就向令牌桶中添加目标数量的令牌，在遇到流量突发的情况下，由于令牌桶在接收请求时会添加令牌，即使令牌添加的速度小于用户请求获取令牌的速度，仍然会有部分用户请求能够从令牌桶中获取到令牌，这部分获取到令牌的用户请求仍旧可以得到处理，可有效解决用户请求过多的情况下，无法处理所有用户请求的问题。

附图说明

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

图1是本申请一个实施例提供的限流方法的流程示意图；

图2是本申请实施例提供的一种限流装置的结构示意图；

图3是是本申请实施例提供的电子设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

限流是指对系统的出入流量进行控制，防止大量出入，导致资源不足，系统不稳定。限流系统是对资源访问的控制组件，其中，控制组件具有两个功能：限流策略和熔断策略。熔断策略指的是超出速率阈值的请求的处理策略。常见的熔断策略诉求包括：(1)直接拒绝；(2)排队等待；(3)服务降级；(4)自定义熔断策略等。常见的限流算法分为两类：计数限流算法和非计数限流算法。计数限流算法常见的有固定窗口计数，滑动窗口计数，滑动窗口日志；非计数限流算法常见的有令牌桶限流算法和漏桶限流算法。

现有技术中，平台接口流量控制系统是为数据平台的接口服务提供相应的流量控制处理，以保证数据平台接口能够稳定高效地提供服务。根据相关限流算法，使用远程字典服务(Remote Dictionary Server，redis)集群技术，对分布式数据平台接口服务实现请求服务频率的控制。防止接口服务因高频的请求而导致系统崩溃，增强系统的稳健性。一般的微服务架构，通常的设计是通过epoll(Linux内核为处理大批量文件描述符而作了改进的poll)实现多路复用，将请求压入缓存队列，起多个worker对请求进行处理。在高负载场景下，这个时候worker无法及时处理请求，用户大量进行重试，这个时候队列中的内容取出时很多都已经失效了。这个时候再进行处理已经没有意义，做的都是无用功，对外的表现就是一直不可用，服务发生雪崩。

为了解决现有技术问题，本申请实施例提供了一种限流方法、装置、设备、介质及产品。下面首先对本申请实施例所提供的限流方法进行介绍。

根据该实施例的应用场景可以包括终端设备，网络和服务器。网络用以在终端设备和服务器之间提供通信链路的介质。网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备通过网络与服务器交互，以接收或发送消息等。终端设备上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器可以是提供各种服务的服务器，例如对用户利用终端设备所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

图1示出了本申请一个实施例提供的网络异常检测方法的流程示意图。如图1所示，该方法具体可以包括如下步骤：

S101，根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差。

可选地，令牌桶技术(Token Bucket)是一种常见的流量测量技术，常用于流量的限制和流量的整形，能够对流量的速率和突发进行测量。本申请所提供的限流方法即是在令牌桶技术的基础上实现的。令牌即是存放在令牌桶中的，用于相应用户业务请求的令牌。令牌的数量指的是令牌桶中令牌的数量。

可选地，预设添加速率即为单位时间内向令牌桶添加令牌的数量，可选地，预设添加速率可以根据令牌桶自身的属性确定，其中令牌桶的属性至少包括历史添加令牌时间、预设添加速率。

具体的，在本申请实施例中，假设当前时间记为curr_mill_second，上一次向令牌桶添加令牌的时间记为last_mill_second，则第一时间段即时间差diff_second＝(curr_mill_second-last_mill_second)/1000(时间单位均为毫秒数)。假设预设添加速率记为rate，则向令牌桶中添加目标数量的令牌记为reserve_tokens＝diff_second*rate。由此计算出第一时间段需要添加令牌的数量。需要说明的是，在令牌桶刚创建时，上一次添加令牌的时间为空值，直接向令牌桶中添加curr_mill_second*rate数量的令牌。

在本申请实施例中，通过将令牌桶中每次添加令牌的时间存储在自身的令牌桶中，能够有效节省服务器的存储空间，节省硬件的成本。

S102，向令牌桶中添加目标数量的令牌。

在计算得到需要添加的令牌数(目标数量)以后，以预设添加速率向令牌桶中添加令牌。

可选地，在本申请实施例中，在添加完令牌以后，需要更新上一次向令牌桶中添加令牌的时间，如果目标数量小于1，则不更新上一次向桶里添加令牌的时间。

S103，在接收到第一用户请求的情况下，从令牌桶中获取令牌。

可选地，用户请求指的是用户在准备接入为用户提供业务需求的平台时，向平台发送的接入请求。第一用户请求即为当前用户请求。

可选地，在本申请实施例中，将向令牌桶中添加令牌的动作给为触发式的方式，即在用户请求取令牌的同时，向令牌桶中添加令牌。由此能够在每次接收用户请求时，就向令牌桶中添加目标数量的令牌，由此在遇到流量突发的情况，即使前一个用户请求无法从令牌桶中获取到令牌，但是由于令牌桶在接收请求时一直在添加令牌，由此仍然会有一部分用户请求能够从令牌桶中获取到令牌，使得用户请求能够得到处理。

S104，在从所述令牌桶中获取到第一令牌的情况下，对所述第一用户请求进行处理。

可选地，在计算目标数量后，需要计算令牌桶中实际可用的令牌数。可选地，第一令牌即为与第一用户请求对应的所需的令牌桶中的令牌。

具体而言，假设令牌桶中上一次添加令牌以后令牌桶中的令牌数记为last_tokens，则向令牌桶中添加目标数量的令牌以后，令牌桶中的预期令牌数即为expect_tokens＝last_tokens+math.floor(reserve_tokens)，其中，reserve_tokens即为上述的目标数量，math.floor即为向下取整，例如计算得到的目标数量为4.2，向下取整以后即为4。由于令牌桶的容量是确定，假设计算得到的预期令牌数大于令牌桶的容量，那么令牌桶中的可用令牌数即为对应令牌桶的容量；若计算得到的预期令牌数小于令牌桶的容量，那么令牌桶中的可用令牌数即为预期令牌数。

随后比较第一用户请求所需的令牌数和令牌桶中的可用令牌数的大小，确定是否能够处理第一用户请求。具体而言，在第一用户请求所需的令牌数小于或等于令牌桶中的可用令牌数的情况下，第一用户请求从令牌桶中获取所需数量的令牌，允许待处理请求通过，并处理第一用户请求。

S104，在从所述令牌桶中未获取到第一令牌的情况下，不对所述第一用户请求进行处理。

可选地，以上述实施例为例，若第一用户请求所需的令牌数大于令牌桶中的可用令牌数，执行熔断操作，具体地，熔断操作可以是拒绝该第一用户请求通过、排队等待处理等，具体的熔断操作本申请不做限制，可以根据用户请求的类型具体设置。

在本申请实施例提供的一种限流方法、装置、设备、介质及产品中，通过根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，其中，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；随后向令牌桶中添加目标数量的令牌；然后在接收到第一用户请求的情况下，从令牌桶中获取令牌；随后在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；然后在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。通过上述方式，能够通过每次添加令牌的时间，确定每次接收用户请求时添加的令牌数量，即在每次接收用户请求时，就向令牌桶中添加目标数量的令牌，在遇到流量突发的情况下，由于令牌桶在接收请求时会添加令牌，即使令牌添加速率小于用户请求获取令牌的速度，仍然会有一部分用户请求能够从令牌桶中获取到令牌，这部分获取到令牌的用户请求仍旧可以得到处理，可有效解决用户请求过多的情况下，无法处理所有用户请求的问题，本申请的限流方法流量通过时比较平滑，并且可以抵挡一定的流量突发情况。

在一实施例中，在上述步骤101之前，该方法可以具体执行如下步骤：

S201，在接收到第二用户请求的情况下，从令牌桶中获取令牌。

S202，在从所述令牌桶中未获取到第二令牌的情况下，根据第一时间段，以及所述第一时间段内预设速率，确定向所述令牌桶中添加目标数量的令牌。

可选地，在本申请实施例中，第二用户请求可以是上一次的用户请求，第一用户请求为当前接收的用户请求。第二令牌为与第二用户请求对应的所需的令牌桶中的令牌。

在本申请实施例中，在接收到第二用户请求以后，需要从令牌桶中获取第二用户请求所需的令牌数，此时，触发令牌桶执行添加令牌的动作，由此，在每一次接收到用户请求时，都能够触发令牌桶执行添加令牌的操作，从而能够在遇到流量突发的情况，即使前一个用户请求无法从令牌桶中获取到令牌，但是由于令牌桶在接收请求时一直在添加令牌，由此仍然会与一部分用户请求能够从令牌桶中获取到令牌，使得用户请求能够得到处理。

可选地，在本申请实施例中，在实现向令牌桶中放入令牌时，可以将令牌持久化到redisson(Redisson是架设在Redis基础上的一个Java驻内存数据网格)缓存中，采用redislua脚本实现逻辑，即通过lua脚本执行redis命令，lua是reids支持的可执行的动态脚本语言；能够保证操作原子性，实现集群环境中用户接口访问的原子限流，避免并发访问下令牌桶令牌数量设置错误的情况，保证多台网关服务共享流量限制，提升令牌桶获取令牌和添加令牌的准确率。

在一实施例中，上述步骤201具体可以执行如下步骤：

S2011，在接收到第二用户请求的情况下，根据第二用户请求的请求类型，确定所述请求类型对应的令牌桶结构，所述令牌桶结构包括所述令牌桶的容量以及所述令牌桶的预设添加速率。

S2012，从所述令牌桶中获取令牌。

可选地，用户请求的请求类型可以理解为服务平台分配给客户系统的唯一标识接入的appKey，是为了可以精细限制具体哪个客户使用什么业务类型服务接口的频率。业务类型可以认为是一个业务服务接口。比如：可以控制客户A系统，在一秒钟或一分钟或者一个小时内能访问业务1服务接口多少次；还可以是在特定时段内的访问频次等。

在这些可选的实施例中，可以根据业务服务来控制每个请求类型的访问频率。并精细到具体某个客户对业务服务的访问频次。这样就能够灵活控制各种不同服务的使用频率，设置不同的令牌桶结构，有效地解决突发流量问题；并且，在本申请实施中，还可以可按应用+业务类型来控制服务器的使用频率，可按每秒/每分钟/每小时/每天不同时间等级来控制相关业务服务的调用次数。

可选地，在本申请一种可能的方案中，通过不同的请求类型，设置多个令牌桶，并给不同的令牌桶结构，从而能够灵活控制向令牌桶中添加令牌的速率；不同的请求又对应不同的令牌桶，这样就能够灵活控制各种不同服务的使用频率，对不同服务的重要性作出分级，保证更重要的服务受到的影响更低，防止恶意攻击或不可预知的外部流量击垮业务系统。

可选地，在本申请另一种可能的实现方式中，可以通过接口限流管理模块实现对不同请求类型的限流规则管理。接口限流管理模块主要是对平台接口按照不同的需求设置不同的限流规则，从而实现接口不同粒度下的限流服务。限流粒度包括接口请求总限；客户账号请求的总限；接口各自的总限，以及账号和接口组合的请求总限。该模块可以根据不同的场景，来采用不同粒度下的限流规则。能够灵活控制各种不同服务的使用频率，对不同服务的重要性作出分级，保证更重要的服务受到的影响更低，防止恶意攻击或不可预知的外部流量击垮业务系统。

在这些可选的实施例中，针对平台接口服务的不同需求实现接口请求的流量限制，确保接口服务的稳定性。并采用redis分布式集群存储系统，根据限流算法实现不同场景下分布式接口服务的限流功能。确保平台接口能够对系统出入流量进行控制，防止大量出入，导致资源不足，系统不稳定的情况。

在一实施例中，上述步骤102可以具体执行如下步骤：

S1021，若当前存放的令牌数小于所述令牌桶的容量，则向所述令牌桶中添加小于或等于所述目标数量的令牌，添加之后的所述令牌桶中的令牌数小于或等于所述容量。

具体的，步骤104的例子中，假设令牌桶的容量为L，令牌桶中原有的令牌数记为last_tokens，则令牌桶添加的令牌数与令牌桶原有的令牌数之和为expect_tokens＝last_tokens+math.floor(reserve_tokens)，令牌桶中现有的令牌数记为local_curr_tokens，local_curr_tokens＝math.min(expect_curr_tokens,max_tokens)，其中math.min即为取最小值，若expect_tokens≥H，则local_curr_tokens＝H，即把大于桶容量的令牌丢弃，若expect_tokens＜H，则local_curr_tokens＝expect_tokens。由此，能够限制令牌桶中的令牌数，避免或减少令牌桶一直添加令牌，导致请求无法处理的情况发生。

在一实施例中，上述步骤103可以具体执行如下步骤：

S1041，获取所述第一用户请求中的报文长度；

S1042，根据所述报文长度，确定所述第一服务请求所需的令牌数；

S1043，在所述令牌桶中可使用的令牌数大于所述第一用户请求所需的令牌数的情况下，从所述令牌桶中获取第一令牌。

在一个实施例中，报文是网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变，因此，具体的报文长度可以根据第一用户请求的报文的字节大小确定。

可选地，由上文描述可知，用户请求具有不同的请求类型，因此不同的请求类型的用户请求的所需的令牌数可以不同。

作为本发明另一个实施例，不同请求类型对应的所需令牌数通过以下公式计算得到：

need_tokens(i)＝S(i)*V(i)*U(i)

其中，S(i)表示i类型的用户请求的平均耗时比率，V(i)表示i类型的用户请求对应的每秒添加令牌数，U(i)表示i类型的用户请求对应的调节因子，need_tokens(i)表示i类型的用户请求对应的所需令牌数。

在本申请实施例中，用户请求的平均耗时是指从用户请求接入令牌桶到取令牌离开的时间差值，那么某一类型的用户请求的平均处理耗时可以通过令牌桶处理该类型的用户请求的耗时之和除以该类型的用户请求数量而得到。因此，i类型的用户请求的平均耗时比率＝i类型的用户请求的平均耗时/所有类型的用户请求的平均耗时之和，0＜S(i)≤1。可以基于现有的开源框架或者基于Spring AOP(Aspect-OrientedProgramming，面向切面编程)统计每个接入令牌桶的用户请求的平均处理耗时，从而计算得到各个类型的用户请求对应的平均处理耗时。因此，可以通过用户请求的平均处理耗时与令牌添加速率的乘积，再乘以调节因子，获取的结果向上取整，从而计算出该用户请求对应的所需令牌数。需要指出的是，调节因子是一个扩展调节参数，可以对不同应用、不同业务配置不同的调节因子，调节因子的大小会直接影响到各个类型用户请求对应的所需令牌数，因此可以直接使用该扩展因子进行调节。比如可以将数据包长度比率作为调节因子，或者根据需要设置调节因子的大小。

在这些可选的实施例中，通过计算得到每个用户请求所需的令牌数，从而能够根据每个用户请求所需的令牌数确定令牌桶中的可用令牌是否能够满足用户请求所需的令牌数，提高了流量通过的准确率。

图2示出了本申请另一个实施例提供的限流装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图2，限流测装置可以包括：

第一确定模块201，用于根据第一时间段，以及第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，第一时间段为上一次向令牌桶添加令牌的时间和当前时间之间的时间差；

添加模块202，用于向令牌桶中添加目标数量的令牌；

第一获取模块203，用于在接收到第一用户请求的情况下，从令牌桶中获取令牌；

第一处理模块204，用于在从令牌桶中获取到第一令牌的情况下，对第一用户请求进行处理；

第二处理模块205，用于在从令牌桶中未获取到第一令牌的情况下，不对第一用户请求进行处理。

在一实施例中，限流装置还可以包括：

第二获取模块，用于在接收到第二用户请求的情况下，从令牌桶中获取令牌；

第二确定模块，用于在从所述令牌桶中未获取到第二令牌的情况下，根据第一时间段，以及所述第一时间段内预设速率，确定向所述令牌桶中添加目标数量的令牌。

在一实施例中，限流装置还可以包括：

第三确定模块，用于在接收到第二用户请求的情况下，根据第二用户请求的请求类型，确定所述请求类型对应的令牌桶结构，所述令牌桶结构包括所述令牌桶的容量以及所述令牌桶的预设添加速率；

第三获取模块，用于从所述令牌桶中获取令牌。

在一实施例中，限流装置还可以包括：

第二添加模块，用于若当前存放的令牌数小于所述令牌桶的容量，则向所述令牌桶中添加小于或等于所述目标数量的令牌，添加之后的所述令牌桶中的令牌数小于或等于所述容量。

在一实施例中，限流装置还可以包括：

第四获取模块，用于获取所述第一用户请求中的报文长度；

第四确地模块，用于根据所述报文长度，确定所述第一服务请求所需的令牌数；

第五获取模块，用于在所述令牌桶中可使用的令牌数大于所述第一用户请求所需的令牌数的情况下，从所述令牌桶中获取第一令牌。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，与本申请方法实施例基于同一构思，是与上述电池热失控预警方法对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图3示出了本申请实施例提供的电子设备的硬件结构示意图。

设备可以包括处理器301以及存储有程序指令的存储器302。

处理器301执行程序时实现上述任意各个方法实施例中的步骤。

示例性的，程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器302中，并由处理器301执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列程序指令段，该指令段用于描述程序在设备中的执行过程。

具体地，上述处理器301可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器302可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器302可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器302可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器302可在综合网关容灾设备的内部或外部。在特定实施例中，存储器302是非易失性固态存储器。

存储器可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本公开的一方面的方法所描述的操作。

处理器301通过读取并执行存储器302中存储的程序指令，以实现上述实施例中的任意一种方法。

在一个示例中，电子设备还可包括通信接口303和总线310。其中，处理器301、存储器302、通信接口303通过总线310连接并完成相互间的通信。

通信接口303，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线310包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线310可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的方法，本申请实施例可提供一种存储介质来实现。该存储介质上存储有程序指令；该程序指令被处理器执行时实现上述实施例中的任意一种方法。

本申请实施例另提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

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

以上的结构框图中所示的功能模块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网格被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种限流方法，其特征在于，所述方法包括：

根据第一时间段，以及所述第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，所述第一时间段为上一次向所述令牌桶添加令牌的时间和当前时间之间的时间差；

向所述令牌桶中添加所述目标数量的令牌；

在接收到第一用户请求的情况下，从所述令牌桶中获取令牌；

在从所述令牌桶中获取到第一令牌的情况下，对所述第一用户请求进行处理；

在从所述令牌桶中未获取到第一令牌的情况下，不对所述第一用户请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述根据第一时间段，以及所述第一时间段内预设速率，确定向令牌桶中添加目标数量的令牌之前，包括：

在接收到第二用户请求的情况下，从所述令牌桶中获取令牌；

在从所述令牌桶中未获取到第二令牌的情况下，根据所述第一时间段，以及所述第一时间段内预设速率，确定向所述令牌桶中添加目标数量的令牌。

3.根据权利要求2所述的方法，其特征在于，所述在接收到第二用户请求的情况下，从令牌桶中获取令牌，包括：

在接收到所述第二用户请求的情况下，根据所述第二用户请求的请求类型，确定所述请求类型对应的令牌桶结构，所述令牌桶结构包括所述令牌桶的容量以及所述令牌桶的预设添加速率；

从所述令牌桶中获取令牌。

4.根据权利要求1所述的方法，其特征在于，所述向所述令牌桶中添加所述目标数量的令牌，包括：

若当前存放的令牌数小于所述令牌桶的容量，则向所述令牌桶中添加小于或等于所述目标数量的令牌，添加之后的所述令牌桶中的令牌数小于或等于所述容量。

5.根据权利要求3所述的方法，其特征在于，所述在接收到第一用户请求的情况下，从所述令牌桶中获取令牌，包括：

获取所述第一用户请求中的报文长度；

根据所述报文长度，确定所述第一服务请求所需的令牌数；

在所述令牌桶中可使用的令牌数大于所述第一用户请求所需的令牌数的情况下，从所述令牌桶中获取第一令牌。

6.一种限流装置，其特征在于，所述装置包括：

第一确定模块，用于根据第一时间段，以及所述第一时间段内预设添加速率，确定向令牌桶中添加目标数量的令牌，所述第一时间段为上一次向所述令牌桶添加令牌的时间和当前时间之间的时间差；

添加模块，用于向所述令牌桶中添加所述目标数量的令牌；

第一获取模块，用于在接收到第一用户请求的情况下，从所述令牌桶中获取令牌；

第一处理模块，用于在从所述令牌桶中获取到第一令牌的情况下，对所述第一用户请求进行处理；

第二处理模块，用于在从所述令牌桶中未获取到第一令牌的情况下，不对所述第一用户请求进行处理。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于在接收到第二用户请求的情况下，从所述令牌桶中获取令牌；

第二确定模块，用于在从所述令牌桶中未获取到第二令牌的情况下，根据所述第一时间段，以及所述第一时间段内预设速率，确定向所述令牌桶中添加目标数量的令牌。

8.一种电子设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-5任意一项所述的限流方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-5任意一项所述的限流方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如权利要求1-5任意一项所述的限流方法。

Images