CN110611623A - 限流方法和装置 - Google Patents

Abstract

本申请涉及一种限流方法和装置，所述方法包括：根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；在接收到请求时，根据该请求所携带的信息确定该请求所对应的令牌桶；根据对应的令牌桶中剩余的令牌数量对该请求进行处理。本申请的方案设置多个令牌桶，并给不同的令牌桶设置不同的属性，从而能够灵活控制各个向令牌桶中添加令牌的速率；不同的请求又对应不同的令牌桶，这样就能够灵活控制各种不同接口的使用频率，对不同接口的重要性作出分级，保证更重要的接口受到的影响更低，防止恶意攻击或不可预知的外部流量击垮业务系统。

Description

限流方法和装置

技术领域

本申请涉及API网关技术领域，具体涉及一种限流方法和装置。

背景技术

电商行业经常会有大量的促销活动，比如各种传统节日、双11、双旦等活动，促销活动期间会集中地产生大量订单。对于电商平台来说，用户的下单、查询等一系列操作会带来流量集中式地爆发。非预期的请求量会对系统带来极大的冲击，但是实际业务系统的负载能力是有限的，为防止对业务系统带来的压力过大而拖垮系统，需要对服务接口引入限流策略。限流虽然会降低和拒绝一些服务接口的访问频率和并发量，但换取了服务接口和业务系统的高可用。系统中的流量控制常用处理手段有：计数器方式、滑动窗口方式、漏桶方式、令牌桶方式。

计数器是一种比较简单粗暴的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限流。具体做法是，在一段时间内进行计数，并与阀值进行比较，到了时间临界点时将计数器清0。需要注意的是，这里就存在一个时间临界点的问题。举个例子：在12:01:00到12:01:58这段时间内没有用户请求，然后在12:01:59这一瞬时发出100个请求，然后在12:02:00这一瞬时又发出了100个请求。在这个临界点可能会承受恶意用户的大量请求，甚至超出系统预期的承受。

由于计数器存在临界点缺陷，后来出现了滑动窗口算法来解决。滑动窗口的做法是，把固定时间片进行划分，并且随着时间的流逝进行移动，这样就巧妙地避开了计数器的临界点问题。也就是说，这些固定数量的可以移动的格子，将会进行计数、判断阀值，因此格子的数量影响着滑动窗口算法的精度。

虽然滑动窗口有效避免了时间临界点的问题，但是依然有时间片的概念，而漏桶算法在这方面比滑动窗口更加先进。可以将漏桶比作一个固定的桶，进水的速率是不确定的，但是出水的速率是恒定的，当水满的时候是会溢出的。简单地说，漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，当流入的请求数累积到漏桶容量时，则新流入的请求全部会被拒绝。

上面提到的三种流量控制方式都有不足的地方，而且均是针对单机而言的，这种单机模式无法满足和解决在分布式系统环境下的全局限流问题。生产环境通常是分布式系统布署，具有多个节点且多个节点最终调用的又是同一个业务接口。虽然对单个节点能做到将QPS限制在n/s，但是多节点条件下，如果每个节点均是n/s，那么到业务接口的总请求就是(节点数×n)/s，这么一来限流的效果将失效。

发明内容

为至少在一定程度上克服相关技术中存在的问题，本申请提供一种限流方法和装置。

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

根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；

在接收到请求时，根据该请求所携带的信息确定该请求所对应的令牌桶；

根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

进一步地，所述以触发的方式分别向不同的令牌桶中添加令牌，包括：

当触发事件发生时，根据令牌桶的属性确定需要添加的令牌数量；

生成相应数量的令牌添加到令牌桶中。

进一步地，所述令牌桶的属性至少包括：历史毫秒数、初始速率；

相应地，所述根据令牌桶的属性确定需要添加的令牌数量，包括：

需要添加的令牌数量＝(当前时间的毫秒数-历史毫秒数)÷1000×初始速率；

其中，所述历史毫秒数为上一次添加令牌的时间的毫秒数。

进一步地，所述方法还包括：

添加令牌后，更新所述历史毫秒数。

进一步地，所述触发事件为取令牌；

所述方法还包括：

生成相应数量的令牌添加到令牌桶中之后，再执行取令牌的步骤。

进一步地，所述令牌桶的属性包括如下项中的至少一项：应用种类、业务类型。

进一步地，所述根据该请求所携带的信息确定该请求所对应的令牌桶，包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型筛选出对应的令牌桶。

进一步地，所述方法还包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型判断是否需要限流；

如果不需要限流，直接放行该请求并进行后续处理；

如果需要限流，则根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

进一步地，所述根据对应的令牌桶中剩余的令牌数量对该请求进行处理，包括：

如果令牌桶中剩余的令牌数量为0，则拒绝处理该请求并返回错误提示；

如果令牌桶中剩余的令牌数量不为0，则放行该请求并进行后续处理。

根据本申请实施例的第二方面，提供一种限流装置，包括：

添加模块，根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；

确定模块，用于在接收到请求时，根据该请求所携带的信息确定请求所对应的令牌桶；

处理模块，用于根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

本申请的实施例提供的技术方案具备以下有益效果：

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

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的一种限流方法的流程图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种限流方法的流程图。该方法可以应用于API接口的限流，包括以下步骤：

步骤S1：根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；需要说明的是，令牌桶的属性是预先配置好的，可以根据业务的需要灵活配置。

步骤S2：在接收到请求时，根据该请求所携带的信息确定该请求所对应的令牌桶；由于存在多个不同的令牌桶，分别对多种不同类型的请求进行限流处理，因而首先需要根据请求中携带的信息确定应该到哪个令牌桶中去取令牌。

步骤S3：根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

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

现有的令牌桶算法，是启动一个不断重复执行的线程，线程根据配置往令牌桶里面添加令牌。但是这个实现方式是有缺点的：1、需要为每个令牌桶去配置添加一个重复执行的线程；2、重复的间隔精度不够精确，比如：线程需要每1/rate秒向桶中添加一个令牌，当rate大于1000时，该线程执行的时间间隔没有办法去设置；而实际的业务场景中，接口访问频率远远不止1000。

基于上述的缺点，本申请的方案使用的是触发方式来添加令牌，是基于现有的令牌桶算法做出了改进。具体执行逻辑是：

1、将添加令牌改成触发式的方式，取令牌的同时做添加令牌的动作；

2、在取令牌的时候，通过计算上一次添加令牌和当前的时间差，计算出这段时间应该添加的令牌数量，然后往桶里添加；应该添加的令牌数量＝(当前时间毫秒数–上一次添加令牌的毫秒数)/1000×添加令牌的速率；

3、添加完令牌之后再执行取令牌逻辑；

4、令牌桶在刚刚创建的时候，上一次获取令牌的毫秒数为空；根据上一次向桶里添加令牌的时间和当前时间差，触发式的往桶中添加令牌，并且更新上一次向桶里添加令牌的时间，如果向桶里添加的令牌数不足一个，则不更新上一次向桶里添加令牌的时间。

一些实施例中，所述以触发的方式分别向不同的令牌桶中添加令牌，包括：

当触发事件发生时，根据令牌桶的属性确定需要添加的令牌数量；

生成相应数量的令牌添加到令牌桶中。

一些实施例中，所述令牌桶的属性至少包括：历史毫秒数、初始速率；

相应地，所述根据令牌桶的属性确定需要添加的令牌数量，包括：

需要添加的令牌数量＝(当前时间的毫秒数-历史毫秒数)÷1000×初始速率；

其中，所述历史毫秒数为上一次添加令牌的时间的毫秒数。初始速率是预设的常量数值，其意义是每一秒钟添加的令牌数量。

一些实施例中，所述方法还包括：

添加令牌后，更新所述历史毫秒数。

一些实施例中，所述触发事件为取令牌；

所述方法还包括：

生成相应数量的令牌添加到令牌桶中之后，再执行取令牌的步骤。

也就是说，每次收到请求，该请求取令牌时，令牌桶会先触发添加令牌的动作，再执行取令牌的动作。

一些实施例中，所述令牌桶的属性包括如下项中的至少一项：应用种类、业务类型。

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

当然这里的应用类型(客户appKey)也是可以缺省配置成缺省值，这样就可以只根据业务服务接口来控制访问频率。这里在后台的配置是相对比较灵活的。可笼统地控制接口，也可以精细到具体某个客户对业务服务接口的访问频次。

一些实施例中，所述根据该请求所携带的信息确定该请求所对应的令牌桶，包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型筛选出对应的令牌桶。

需要说明的是，每个请求的请求头里面是必须携带服务平台分配给客户(请求端)的appKey(应用标识)和需要访问的业务类型的。服务平台接到请求后，即可从请求头中获取这两个字段的值。

appKey(应用标识)在每个业务接口需不需要限流，需要按什么级别限流，在系统启动过程中已经加载到每个节点的Local Cache，如果后台配置发生变更会广播通知每个接口重新加载最新数据。

请求通过LocalCache的数据就可以知道是不是是不是需要限流，如果需要限流则按appKey+业务类型+时间等级就可以确定需要访问去哪个令牌桶获取token，如果不需要限流请求直接放过。

如果取到了token做后续处理，参数校验，报文验签，身份检查，报文转换，分发业务系统等一系列动作，如果取不到token则直接返回403，并告知对方请求不可达。

一些实施例中，所述方法还包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型判断是否需要限流；

如果不需要限流，直接放行该请求并进行后续处理；

如果需要限流，则根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

一些实施例中，所述根据对应的令牌桶中剩余的令牌数量对该请求进行处理，包括：

如果令牌桶中剩余的令牌数量为0，则拒绝处理该请求并返回错误提示；

如果令牌桶中剩余的令牌数量不为0，则放行该请求并进行后续处理。

本申请的方案引入令牌桶算法模型，有效地解决突发流量问题；可按应用+业务类型来控制接口的使用频率，可按每秒/每分钟/每小时/每天不同时间等级来控制各应用对物流相关业务接口的调用次数。

从原有的单机控制流量改进为分布式环境下进行全局的流量控制，接口调用的频次计算上更加准确，同时支持通过管理控制台进行应用、业务在不同时间维度的接口调用频次设置，可实时调整流控的阈值，在大促期间更有效的防御突如其来的流量对下游业务系统的冲击，选择性的对边缘业务做降级处理，保障核心主链路不受影响。

下面结合具体的应用场景，对本申请的方案进行拓展说明。

一、实现令牌桶算法模型解决漏桶的问题，该算法模型是一个存放固定容量令牌的桶，通过程序按照固定速率往桶里添加令牌，且令牌可以根据应用+业务类型+时间等级(每秒/每分钟/每小时/每天)不同维度区分配置，这样就可以按业务场景的要求来灵活配置令牌的发放速率。请求是否被处理需检查桶内令牌是否足够，当令牌数量减为零时则拒绝新的请求；令牌桶能够控制平均流入速率，并允许一定程度突发流量(允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌、4个令牌或n个令牌)。

这里的时间等级，可以理解为按不同的时间细分度，比如有的接口访问频率很高，可以按1秒钟允许发放多少个令牌，有的接口需要限制一个小时的量即可，或者一天能访问最多多少次访问，可以根据业务的需要来配置。

二、分布式系统下限流最为关键的是要将限流服务做成原子化，因此我们的解决方案采用Redis+Lua技术进行实现。使用Redis进行限流，因其很好地解决了分布式环境下多实例所导致的并发问题，因使用Redis设置的计时器和计数器均是全局唯一的，不管多少个节点，它们使用的都是同样的计时器和计数器，可以做到精准的流控，并且保证取令牌和生成令牌两个操作的原子性。

其中，原子性是指一个业务逻辑必须不可拆分，比如一个转账业务，必须包括一个账号扣钱、另一个账号增加钱。这个业务就是原子性的，这个操作就是原子操作，要么成功要么失败，redis所有单个命令的执行都是原子性的。

在redis中实现事务的原理是：

1、批量操作在发送EXEC命令前被放入队列缓存；

2、收到EXEC命令后进入事务执行，事务中任意命令执行失败，其余的命令都不会被执行；

3、在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

所以本申请的方案选择使用redis+lua用命令的方式提交操作保证原子性。在分布式环境中各节点数据是共用的一套redis集群，数据是同一份。利用了redis和lua的组合特性，来保证了并发下的原子性问题。

三、缓存中用MAP数据结构来存储，支持按不同的应用+业务类型+时间维度控制token发放，拿秒级作为代表，我们设计相关属性包括：最后时间毫秒、当前可用的令牌数、令牌桶的最大值、每秒生成几个令牌、应用、业务类型。

不同的维度可通过后台管理功能按大促期间的峰值来设定一个值，这个值是可以通过配置功能随时调整的。

四、分别按每分钟/每小时/每天统计调用次数。令牌桶可以按照分钟、小时、天不同的时间细分度去配置限流条件，因为从业务上考虑，不是所有的业务都是按分钟去做流控的，实际是存在某个客户按天来统计控制他们系统对系统服务接口的调用。

五、生产令牌每次获取token时根据时间戳生成token，不超过最大值。

本申请还提供如下的实施例：

一种限流装置，包括：

添加模块，根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；

确定模块，用于在接收到请求时，根据该请求所携带的信息确定请求所对应的令牌桶；

处理模块，用于根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

关于上述实施例中的装置，其中各个模块执行操作的具体步骤已经在有关该方法的实施例中进行了详细描述，此处不再详细阐述说明。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

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

根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；

在接收到请求时，根据该请求所携带的信息确定该请求所对应的令牌桶；

根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

2.根据权利要求1所述的方法，其特征在于，所述以触发的方式分别向不同的令牌桶中添加令牌，包括：

当触发事件发生时，根据令牌桶的属性确定需要添加的令牌数量；

生成相应数量的令牌添加到令牌桶中。

3.根据权利要求2所述的方法，其特征在于，所述令牌桶的属性至少包括：历史毫秒数、初始速率；

相应地，所述根据令牌桶的属性确定需要添加的令牌数量，包括：

需要添加的令牌数量＝(当前时间的毫秒数-历史毫秒数)÷1000×初始速率；

其中，所述历史毫秒数为上一次添加令牌的时间的毫秒数。

4.根据权利要求3所述的方法，其特征在于，还包括：

添加令牌后，更新所述历史毫秒数。

5.根据权利要求2-4任一项所述的方法，其特征在于：所述触发事件为取令牌；

所述方法还包括：

生成相应数量的令牌添加到令牌桶中之后，再执行取令牌的步骤。

6.根据权利要求1-4任一项所述的方法，其特征在于，所述令牌桶的属性包括如下项中的至少一项：应用种类、业务类型。

7.根据权利要求5所述的方法，其特征在于，所述根据该请求所携带的信息确定该请求所对应的令牌桶，包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型筛选出对应的令牌桶。

8.根据权利要求1-4任一项所述的方法，其特征在于，还包括：

根据该请求所携带的信息确定对应的应用种类和/或业务类型；

根据对应的应用种类和/或业务类型判断是否需要限流；

如果不需要限流，直接放行该请求并进行后续处理；

如果需要限流，则根据对应的令牌桶中剩余的令牌数量对该请求进行处理。

9.根据权利要求8所述的方法，其特征在于：所述根据对应的令牌桶中剩余的令牌数量对该请求进行处理，包括：

如果令牌桶中剩余的令牌数量为0，则拒绝处理该请求并返回错误提示；

如果令牌桶中剩余的令牌数量不为0，则放行该请求并进行后续处理。

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

添加模块，根据各个令牌桶的属性，以触发的方式分别向不同的令牌桶中添加令牌；

确定模块，用于在接收到请求时，根据该请求所携带的信息确定请求所对应的令牌桶；

处理模块，用于根据对应的令牌桶中剩余的令牌数量对该请求进行处理。