手写RPC-令牌桶限流算法实现，以及常见限流算法

为什么需要服务限流、降级

分布式架构下，不同服务之间频繁调用，对于某个具体的服务而言，可能会面临高并发场景。在这样的情况下，提供服务的每个服务节点就都可能由于访问量过大而引起一系列问题，比如业务处理耗时过长、CPU飘高、频繁Full GC以及服务进程直接宕机等。但是在生产环境中，要保证服务的稳定性和高可用性，这时就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。我们再次借助 RPC 框架来分析，RPC 调用包括服务端和调用端。对于服务端来讲一般实现限流、降级算法；对于调用方来说一般实现熔断算法。

加入服务调用方调用某个多服务节点的其中一个实现如下：

此时对于特定的服务节点来说，可能存在多个不同调用者的调用，从而使得节点接收服务量超过其最大承载力。此时如果不采取某种策略进行调整，对应的具体服务可能由于过多调用而崩溃，无法对于提供服务能力。限流算法可以很好解决以上问题：当调用端发送请求过来时，服务端在执行业务逻辑之前先执行限流逻辑，如果发现访问量过大并且超出了限流的阈值，就让服务端直接抛回给调用端一个限流异常，否则就执行正常的业务逻辑。

常见限流算法实现有哪些

常见限流算法实现固定窗口计数器法、滑动窗口计数器法、漏桶算法、令牌桶算法。

令牌桶算法

令牌桶是一个限流容器，容器有最大容量（最大处理能力），每秒或每100ms产生一个令牌（具体取决于业务实现以及机器的最大处理能力），当容器中令牌数量达到最大容量时，令牌数量此时不会增加，只有当请求过来时，才会使得令牌数量减少（只有获取到令牌的请求才会执行业务逻辑），才会不断的以一定的速率生成令牌。

令牌桶限流范围：

假设令牌桶最大容量为n ，每秒产生 r 个令牌

平均速率：则随着时间推延，处理请求的平均速率越来越趋近于每秒处理r 个请求，说明令牌桶算法可以控制平均速率

瞬时速率：如果在一瞬间有很多请求进来，此时来不及产生令牌，则在一瞬间最多只有n 个请求能获取到令牌执行业务逻辑，所以令牌桶算

法也可以控制瞬时速率

在这里提下漏桶，漏桶由于出水量固定，所以无法应对突然的流量爆发访问，也就是没有保证瞬时速率的功能，但是可以保证平均速率

漏桶算法

漏桶算法强调把服务调用比作水滴，当有调用（任务）发生时，将其加入桶中，随后采用某种机制（如：定时器）以一定的速率从桶中取出任务进行处理（相当于桶以一定的速率不断在漏水，也就是【漏桶】算法）

漏桶算法的实现可以借助于Redis实现的消息队列和定时任务。

优点：

实现简单、易于理解。
可以控制限流速率，避免网络拥塞和系统过载。

缺点：

无法应对突然激增的流量，因为只能以固定的速率处理请求，对系统资源利用不够友好。
桶流入水（发请求）的速率如果一直大于桶流出水（处理请求）的速率的话，那么桶会一直是满的，一部分新的请求会被丢弃，导致服务质量下降。

在实际业务场景中一般不适用漏桶算法，基于Redis实现的消息队列，其容量非常大，可以使用，其可以理解为容量无线的桶，在一定程度下不会发生消息丢失。

固定窗口计数器法

固定窗口其实就是时间窗口，其原理是将时间划分为固定大小的窗口，在每个窗口内限制请求的数量或速率，即固定窗口计数器算法规定了系统单位时间处理的请求数量。

假如我们规定系统中某个接口 1 分钟只能被访问 33 次的话，使用固定窗口计数器算法的实现思路如下：

将时间划分固定大小窗口，这里是 1 分钟一个窗口。
给定一个变量 counter 来记录当前接口处理的请求数量，初始值为 0（代表接口当前 1 分钟内还未处理请求）。
1 分钟之内每处理一个请求之后就将 counter+1 ，当 counter=33 之后（也就是说在这 1 分钟内接口已经被访问 33 次的话），后续的请求就会被全部拒绝。
等到 1 分钟结束后，将 counter 重置 0，重新开始计数。

优点：实现简单，易于理解。

缺点：

限流不够平滑。例如，我们限制某个接口每分钟只能访问 30 次，假设前 30 秒就有 30 个请求到达的话，那后续 30 秒将无法处理请求，这是不可取的，用户体验极差！
无法保证限流速率，因而无法应对突然激增的流量。

对于固定窗口计数器算法而言，存在非常严重的一个问题就是临界问题：假设1min内服务器的负载能力为100，因此一个周期的访问量限制在100，然后在第一个周期的最后5s和下一个周期的开始5s时间段内，分别涌入了100的访问量，虽然没有超过每个周期的限制量，但是整体上10s内已经达到了200的访问量，远超服务器的承载能力。

滑动窗口计数器法

滑动窗口计数器算法 算的上是固定窗口计数器算法的升级版，限流的颗粒度更小。

滑动窗口计数器算法相比于固定窗口计数器算法的优化在于：它把时间以一定比例分片 。

例如我们的接口限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次，每个窗口一秒只能处理不大于 60(请求数)/60（窗口数） 的请求，如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。

如下图，假设时间周期为1min，将1min再分为2个小周期，统计每个小周期的访问数量，则可以看到，第一个时间周期内，访问数量为75，第二个时间周期内，访问数量为100，超过100的访问则被限流掉了

很显然， 当滑动窗口的格子划分的越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。

优点：

相比于固定窗口算法，滑动窗口计数器算法可以应对突然激增的流量。
相比于固定窗口算法，滑动窗口计数器算法的颗粒度更小，可以提供更精确的限流控制。

缺点：

与固定窗口计数器算法类似，滑动窗口计数器算法依然存在限流不够平滑的问题。
相比较于固定窗口计数器算法，滑动窗口计数器算法实现和理解起来更复杂一些。

四种限流算法的比较

令牌桶限流算法在RPC服务中的应用

为了实现令牌桶算法，我们并不需要严格按照算法的定义多长时间产生一个令牌，我们只需要当桶中无令牌时，根据（当前系统时间 - 上次令牌生成时间之间的差值）x 令牌生成速率，便可以得到这段时间应该生成的令牌总数，随后取其和容量CAPACITY的最小值即可。

代码实现：

package main.version4.v1.server.rateLimit.impl;import lombok.extern.slf4j.Slf4j;
import main.version4.v1.server.rateLimit.RateLimit;/*** 令牌桶限流算法实现* CAPACITY为令牌桶的最大容量，curCAPACITY为当前令牌桶中令牌的数量，timeStamp为上一次请求获取令牌的时间，* 我们在这里并没有实现计数器每秒产生多少令牌放入容器中，而是记住了上一次请求到来的时间，和这次请求之间的时间差值* 进一步根据RATE计算出这段时间能够产生的令牌数量，取min(CAPACITY, CURCAPAITY)。*/
@Slf4j
public class TokenBucketRateLimitImpl implements RateLimit {// 令牌产生速率(单位ms)private static int RATE;// 桶容量private static int CAPACITY;// 当前桶容量private volatile static int curCapacity;// 时间戳private volatile long timeStamp = System.currentTimeMillis();public TokenBucketRateLimitImpl(int rate, int capacity){RATE = rate;CAPACITY = capacity;curCapacity = CAPACITY;}@Overridepublic synchronized boolean getToken() {// 如果当前桶有剩余，直接返回if(curCapacity > 0){curCapacity--;return true;}// 如果桶无剩余long currentTime = System.currentTimeMillis();// 如果距离上一次的请求的时间大于RATE的时间if(currentTime - timeStamp >= RATE){//计算这段时间间隔中生成的令牌，如果>2,桶容量加上（计算的令牌-1）//如果==1，就不做操作（因为这一次操作要消耗一个令牌）if((currentTime - timeStamp) / RATE >= 2){curCapacity += (int) (currentTime - timeStamp) / RATE - 1;}//保持桶内令牌容量<=CAPACITYif(curCapacity > CAPACITY){curCapacity = CAPACITY;}//刷新时间戳为本次请求timeStamp = currentTime;return true;}return false;}
}