限流之Guava RateLimiter原理

Guava是Java领域优秀的开源项目，它包含了Google在Java项目中使用一些核心库，包含集合(Collections)，缓存(Caching)，并发编程库(Concurrency)，常用注解(Common annotations)，String操作，I/O操作方面的众多非常实用的函数。

Guava的RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。

RateLimiter的类图如上所示，其中RateLimiter是入口类，它提供了两套工厂方法来创建出两个子类。这很符合《Effective Java》中的用静态工厂方法代替构造函数的建议，毕竟该书的作者也正是Guava库的主要维护者，二者配合"食用"更佳。

1、平滑突发限流

使用RateLimiter的静态方法创建一个限流器，设置每秒放置的令牌数为5个。返回的RateLimiter对象可以保证1秒内不会给超过5个令牌，并且以固定速率进行放置，达到平滑输出的效果。

RateLimiter使用令牌桶算法，会进行令牌的累积，如果获取令牌的频率比较低，则不会导致等待，直接获取令牌。

RateLimiter由于会累积令牌，所以可以应对突发流量。在下面代码中，有一个请求会直接请求5个令牌，但是由于此时令牌桶中有累积的令牌，足以快速响应。

RateLimiter在没有足够令牌发放时，采用滞后处理的方式，也就是前一个请求获取令牌所需等待的时间由下一次请求来承受，也就是代替前一个请求进行等待。

怎么理解滞后处理的方式呢？让我们考虑一个场景，有个QPS=1的限流器，当限流器空闲时来了一个请求需要获取100个令牌，这时候我们应该直接等待100秒再开始处理？这样的情况多半会使得结果毫无意义。一种更好的策略是对这个请求放行，就像获取1个令牌一样，然后推迟后续的请求。换句话说，我们允许立即完成对这个请求的授权，然后后续的请求进来就至少得等100s的时间。这保证了请求完成的及时。

2、平滑预热限流

RateLimiter的SmoothWarmingUp是带有预热期的平滑限流，它启动后会有一段预热期，逐步将分发频率提升到配置的速率。

比如下面代码中的例子，创建一个平均分发令牌速率为2，预热期为3秒钟。由于设置了预热时间是3秒，令牌桶一开始并不会0.5秒发一个令牌，而是形成一个平滑线性下降的坡度，频率越来越高，在3秒钟之内达到原本设置的频率，以后就以固定的频率输出。这种功能适合系统刚启动需要一点时间来“热身”的场景。

3、源码分析

看完了RateLimiter的基本使用示例后，我们来学习一下它的实现原理。先了解一下几个比较重要的成员变量的含义。

平滑突发限流

RateLimiter的原理就是每次调用acquire时用当前时间和nextFreeTicketMicros进行比较，根据二者的间隔和添加单位令牌的时间间隔stableIntervalMicros来刷新存储令牌数storedPermits。然后acquire会进行休眠，直到nextFreeTicketMicros。

acquire函数如下所示，它会调用reserve函数计算获取目标令牌数所需等待的时间，然后使用SleepStopwatch进行休眠，最后返回等待时间。

reserveEarliestAvailable是刷新令牌数和下次获取令牌时间nextFreeTicketMicros的关键函数。它有三个步骤，一是调用resync函数增加令牌数，二是计算预支付令牌所需额外等待的时间，三是更新下次获取令牌时间nextFreeTicketMicros和存储令牌数storedPermits。

这里涉及RateLimiter的一个特性，也就是可以预先支付令牌，并且所需等待的时间在下次获取令牌时再实际执行。详细的代码逻辑的解释请看注释。

resync函数用于增加存储令牌，核心逻辑就是(nowMicros - nextFreeTicketMicros) / stableIntervalMicros。当前时间大于nextFreeTicketMicros时进行刷新，否则直接返回。

下面我们举个例子，让大家更好的理解resync和reserveEarliestAvailable函数的逻辑。

比如RateLimiter的stableIntervalMicros为500，也就是1秒发两个令牌，storedPermits为0，nextFreeTicketMicros为1553918495748。线程一acquire(2)，当前时间为1553918496248，首先resync函数计算，(1553918496248 - 1553918495748)/500 = 1，所以当前可获取令牌数为1，但是由于可以预支付，所以nextFreeTicketMicros= nextFreeTicketMicro + 1 * 500 = 1553918496748。线程一无需等待。

紧接着，线程二也来acquire(2)，首先resync函数发现当前时间早于nextFreeTicketMicros，所以无法增加令牌数，所以需要预支付2个令牌，nextFreeTicketMicros= nextFreeTicketMicro + 2 * 500 = 1553918497748。线程二需要等待1553918496748时刻，也就是线程一获取时计算的nextFreeTicketMicros时刻。同样的，线程三获取令牌时也需要等待到线程二计算的nextFreeTicketMicros时刻。

平滑预热限流

上述就是平滑突发限流RateLimiter的实现，下面我们来看一下加上预热缓冲期的实现原理。

SmoothWarmingUp实现预热缓冲的关键在于其分发令牌的速率会随时间和令牌数而改变，速率会先慢后快。表现形式如下图所示，令牌刷新的时间间隔由长逐渐变短。等存储令牌数从maxPermits到达thresholdPermits时，发放令牌的时间价格也由coldInterval降低到了正常的stableInterval。

SmoothWarmingUp的相关代码如下所示，相关的逻辑都写在注释中：

后记

RateLimiter只能用于单机的限流，如果想要集群限流，则需要引入redis或者阿里开源的sentinel中间件，请大家继续关注。

来源：https://www.jianshu.com/p/362d261115e7
作者：程序员历小冰

关注WX公众号:【老司机de程序人生】—学习更多Java技术