RateLimiter源码解析

本文主要是介绍RateLimiter源码解析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

简介

平滑预热限流(SmoothWarmingUp)

平滑突发限流(SmoothBursty) 

Demo

create过程

acquire过程

 

---

简介

限流即流量限制，目的是在遇到流量高峰期或者流量突增时，通过对流量进行限制，以把流量控制在系统所能接受的合理范围之内，不至于让系统被高流量击垮。当达到限制速率时，可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）等。

 Google开源工具包Guava提供了限流工具类RateLimiter，该类基于令牌桶算法来完成限流。令牌桶算法是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。桶中存放的令牌数有最大上限，超出之后就被丢弃或者拒绝。当流量或者网络请求到达时，每个请求都要获取一个令牌，如果能够获取到，则直接处理，并且令牌桶删除一个令牌。如果获取不到，该请求就要被限流，即丢弃或在缓冲区等待。

RateLimiter是一个抽象类，子类SmoothRateLimiter派生了平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)两种实现。继承关系：

 核心参数：

  //当前存储的permitsdouble storedPermits;//最大可存储permitsdouble maxPermits;//两个请求的时间间隔，e.g 当permitsPerSecond=5时，那么请求间隔为200msdouble stableIntervalMicros;/*下一次生成令牌的开始时间由于RateLimiter允许预消费，上次请求预消费令牌后下次请求需要等待相应的时间到nextFreeTicketMicros时刻才可以获取令牌*/private long nextFreeTicketMicros = 0L; 

平滑预热限流(SmoothWarmingUp)

启动后会有一段预热期，逐步将分发频率提升到配置的速率。表现形式为令牌刷新的时间间隔由长逐渐变短。等存储令牌数从maxPermits到达thresholdPermits时，发放令牌的时间价格也由coldInterval降低到了正常的stableInterval。

主要原理是分发令牌的速率会随时间和令牌数而改变，由于涉及数学公式推导，先不研究。（想学习的参考这篇 https://cloud.tencent.com/developer/article/1607090）

平滑突发限流(SmoothBursty) 

• Demo

将qps设置为10，每0.1s左右获取一个令牌。

如果设置完qps后没有请求，此时会存储令牌，请求过来后直接拿到令牌不需要等待。比如休眠10s按10qps可以生成100个令牌，但qps10决定了最大存储10个令牌。

• create过程

  //默认使用平滑突发限流，permitsPerSecond为每秒生成的令牌数public static RateLimiter create(double permitsPerSecond) {return create(permitsPerSecond, SleepingStopwatch.createFromSystemTimer());}//SleepingStopwatch主要用于计时和休眠@VisibleForTestingstatic RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);rateLimiter.setRate(permitsPerSecond); //RateLimiter的setRate方法return rateLimiter;}public final void setRate(double permitsPerSecond) {checkArgument(permitsPerSecond > 0.0 && !Double.isNaN(permitsPerSecond), "rate must be positive");synchronized (mutex()) {//调用SmoothRateLimiter的setRate方法doSetRate(permitsPerSecond, stopwatch.readMicros()); //}}//nowMicros为计时器当前时间@Overridefinal void doSetRate(double permitsPerSecond, long nowMicros) {//更新令牌数和获取令牌时间-resync(nowMicros);//更新请求的时间间隔double stableIntervalMicros = SECONDS.toMicros(1L) / permitsPerSecond;this.stableIntervalMicros = stableIntervalMicros;//第一次调用oldMaxPermits为0，所以storedPermits（桶中令牌个数）也为0doSetRate(permitsPerSecond, stableIntervalMicros);}void resync(long nowMicros) {//若当前时间 > 下次生成令牌开始时间if (nowMicros > nextFreeTicketMicros) {//计算出这段时间内，一共可以生产多少令牌。coolDownIntervalMicros()返回stableIntervalMicros，创建时还未赋值，所以是初始0，newPermits计算结果为无穷大double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();//更新存储令牌数storedPermits = min(maxPermits, storedPermits + newPermits);//更新下次生成令牌开始时间nextFreeTicketMicros = nowMicros;}}//SmoothBursty的coolDownIntervalMicros方法直接返回时间间隔@Overridedouble coolDownIntervalMicros() {return stableIntervalMicros;}@Overridevoid doSetRate(double permitsPerSecond, double stableIntervalMicros) {double oldMaxPermits = this.maxPermits;//更新最大令牌数maxPermits = maxBurstSeconds * permitsPerSecond;if (oldMaxPermits == Double.POSITIVE_INFINITY) {// if we don't special-case this, we would get storedPermits == NaN, belowstoredPermits = maxPermits;} else {//重新计算存储的令牌数，保持与最大令牌数的比例storedPermits =(oldMaxPermits == 0.0)? 0.0 // initial state: storedPermits * maxPermits / oldMaxPermits;}}

 创建完成后，结果如图所示：当前存储令牌0，最大存储令牌为2，两个请求的时间间隔500ms，更新了下次请求时间，maxBurstSeconds是SmoothBursty的属性，表示存储多少s的请求。

• acquire过程

RateLimiter会累积令牌，所以可以应对突发流量。在没有足够令牌发放时，采用滞后处理的方式，也就是前一个请求获取令牌所需等待的时间由下一次请求来承受。

获取令牌时可以分为三种情况：1、令牌数足够，直接获取令牌并更新存储令牌数、生成令牌开始时间 2、当前时间 > 开始生成令牌时间，但令牌数不够，此时会借用令牌，将存储置为0，并计算借用的令牌所需要偿还的时间，保存到下一次开始生成令牌时间 3、当前时间 < 开始生成令牌时间，即上一个请求借用的令牌还没还完时间，此时需要休眠到偿还完时间为止，并再次借用令牌。

public double acquire() {return acquire(1);
}public double acquire(int permits) {//需要等待的时间，当令牌足够或者不够导致第一次借用时，返回为0；//当上次借的令牌花费的时间还没有还完，则一直休眠到还完为止，并再次借用long microsToWait = reserve(permits);//线程休眠stopwatch.sleepMicrosUninterruptibly(microsToWait);return 1.0 * microsToWait / SECONDS.toMicros(1L);
}final long reserve(int permits) {checkPermits(permits);//通过互斥锁保证线程安全synchronized (mutex()) {//计算需要休眠的时间return reserveAndGetWaitLength(permits, stopwatch.readMicros());}
}final long reserveAndGetWaitLength(int permits, long nowMicros) {long momentAvailable = reserveEarliestAvailable(permits, nowMicros);//之所以要减去当前时间，是为了让第一次借用令牌的请求不需要休眠，所以后面的方法对nextFreeTicketMicros的处理比较绕return max(momentAvailable - nowMicros, 0);
}final long reserveEarliestAvailable(int requiredPermits, long nowMicros) {resync(nowMicros);long returnValue = nextFreeTicketMicros;double storedPermitsToSpend = min(requiredPermits, this.storedPermits);double freshPermits = requiredPermits - storedPermitsToSpend;//当令牌数不够，需要借用时，计算借用的令牌需要花费的时间long waitMicros =storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)+ (long) (freshPermits * stableIntervalMicros);this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);//更新令牌数this.storedPermits -= storedPermitsToSpend;return returnValue;
}void resync(long nowMicros) {//如果当前时间>令牌开始生成时间，更新令牌数，更新下次令牌开始生成时间if (nowMicros > nextFreeTicketMicros) {double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();storedPermits = min(maxPermits, storedPermits + newPermits);nextFreeTicketMicros = nowMicros;}}

 

与信号量对比：

一旦从 RateLimiter 获得许可，不需要释放。信号量分配后必须释放。
RateLimiter 控制的是速率，以配置的速率分发许可，速率不变时单位时间内分发的许可量是恒定的。信号量控制的是并发访问的数量，单位时间内分配的次数跟使用许可的时长有关，每次申请使用的时间越短，则单位时间内能分配的次数就越多。

这篇关于RateLimiter源码解析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---