限流模式-Guava的RateLimiter

目前有几种常见的限流方式：
1、通过限制单位时间段内调用量来限流
2、通过限制系统的并发调用程度来限流
3、使用漏桶（Leaky Bucket）算法来进行限流
4、使用令牌桶（Token Bucket）算法来进行限流

具体我们看下第三种和第四中算法，也是我们目前看到的最常见的限流算法
漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)，伪代码如下：

double rate;               // leak rate in calls/s
double burst;              // bucket size in calls

long refreshTime;          // time for last water refresh
double water;              // water count at refreshTime

refreshWater() {
    long  now = getTimeOfDay();
    
    //水随着时间流逝,不断流走,最多就流干到0.
    water = max(0, water- (now - refreshTime)*rate); 
    refreshTime = now;
}

bool permissionGranted() {
    refreshWater();
    if (water < burst) { // 水桶还没满,继续加1
        water ++;
        return true;
    } else {
        return false;
    }
}

漏桶算法其实是悲观的，因为它严格限制了系统的吞吐量，从某种角度上来说，它的效果和并发量限流很类似。漏桶算法也可以用于大多数场景，但由于它对服务吞吐量有着严格固定的限制，如果在某个大的服务网络中只对某些服务进行漏桶算法限流，这些服务可能会成为瓶颈。其实对于可扩展的大型服务网络，上游的服务压力可以经过多重下游服务进行扩散，过多的漏桶限流似乎意义不大。
 

令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.

令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

ratelimiter的简介：Google开源工具包Guava提供了限流工具类RateLimiter,该类基于令牌桶算法(Token Bucket)来完成限流,非常易于使用.RateLimiter经常用于限制对一些物理资源或者逻辑资源的访问速率.它支持两种获取permits接口,一种是如果拿不到立刻返回false,一种会阻塞等待一段时间看能不能拿到.RateLimiter和Java中的信号量(java.util.concurrent.Semaphore)类似,Semaphore通常用于限制并发量.

我们先看看如何创建一个RateLimiter实例：

RateLimiter create(double permitsPerSecond);  // 创建一个每秒包含permitsPerSecond个令牌的令牌桶，可以理解为QPS最多为permitsPerSecond

RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)// 创建一个每秒包含permitsPerSecond个令牌的令牌桶，可以理解为QPS最多为permitsPerSecond，并包含某个时间段的预热期

我们再看看获取令牌的相关方法：

double acquire(); // 阻塞直到获取一个许可，返回被限制的睡眠等待时间，单位秒

double acquire(int permits); // 阻塞直到获取permits个许可，返回被限制的睡眠等待时间，单位秒

boolean tryAcquire();  // 尝试获取一个许可

boolean tryAcquire(int permits);  // 尝试获取permits个许可

boolean tryAcquire(long timeout, TimeUnit unit);  // 尝试获取一个许可，最多等待timeout时间

boolean tryAcquire(int permits, long timeout, TimeUnit unit);  // 尝试获取permits个许可，最多等待timeout时间

我们来看个最简单的例子：

SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMdd HH:mm:ss.SSS");

RateLimiter rateLimiter = RateLimiter.create(2);

while(true) {

    rateLimiter.acquire();

    System.out.println(simpleDateFormat.format(new Date()));

}

运行该例子会得到类似如下结果：

20170323 17:04:03.352

20170323 17:04:03.851

20170323 17:04:04.350

20170323 17:04:04.849

20170323 17:04:05.350

20170323 17:04:05.850

20170323 17:04:06.350

20170323 17:04:06.850

我们从中看到，我们在开始设定的QPS是2，也就是说每秒2个请求，在我们打印的结果中每次结果相隔就是500毫秒。

在ratelimiter中，有两种算法：一种是平滑算法（SmoothBursty）一种是预热型算法（SmoothWarmingUp），他们之间最显著的区别就是ratelimiter的子方法：

// 重设流量相关参数，需要子类来实现，不同子类参数不尽相同，比如SmoothWarmingUp肯定有增长比率相关参数

void doSetRate(double permitsPerSecond, double stableIntervalMicros);

// 计算生成这些许可数需要等待的时间

long storedPermitsToWaitTime(double storedPermits, double permitsToTake);

// 返回许可冷却（间隔）时间

double coolDownIntervalMicros();

其中，storedPermitsToWaitTime这个决定了两种方法的等待时间计算方式的不一样，首先smoothburst的该方法是返回0，也就是说对于smoothburst而言，他里面的令牌会一次性全部给请求，所以他的等待时间=缺少的令牌数×stableIntervalMicros（固定的微妙数），而smoothwarmingup的时间计算方式不是这样的，而是缓慢释放令牌直到threshold,再进行QPS的速度，如下图：

*          ^ throttling
 *          |
 * 3*stable +                  /
 * interval |                 /.
 *  (cold)  |                / .
 *          |               /  .   <-- "warmup period" is the area of the trapezoid between
 * 2*stable +              /   .       halfPermits and maxPermits
 * interval |             /    .
 *          |            /     .
 *          |           /      .
 *   stable +----------/  WARM . }
 * interval |          .   UP  . } <-- this rectangle (from 0 to maxPermits, and
 *          |          . PERIOD. }     height == stableInterval) defines the cooldown period,
 *          |          .       . }     and we want cooldownPeriod == warmupPeriod
 *          |---------------------------------> storedPermits
 *              (halfPermits) (maxPermits)
 *

具体的算法，是按照从右到左计算每次获取的permits×（interval1+interval2）/2,简单来说就是计算从左到右覆盖的面积（开始是梯形面积计算）

还有一个点需要重点说明下：我们可以看下我们获取的每次等待时间

0.0

20170324 14:05:24.201

0.497167

20170324 14:05:24.700

0.499216

20170324 14:05:25.199

0.50035

20170324 14:05:25.699

为什么第一次是0呢？这是因为我们看我们返回的时间值的方法：

void resync(long nowMicros) {
  // if nextFreeTicket is in the past, resync to now
 if (nowMicros > nextFreeTicketMicros) {
    double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();
 storedPermits = min(maxPermits, storedPermits + newPermits);
 nextFreeTicketMicros = nowMicros;
 }
}

也就是说如果当前时间大于下一次预测时间，等待时间为0，因为初始化nextfreeticketmicros=0，所以返回的returnvalue=0，同时会在预测下一次获取令牌的时间，方法为：

long waitMicros =
    storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)
        + (long) (freshPermits * stableIntervalMicros);

this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);