限流模式-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);

 

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值