什么是RateLimiter
RateLimiter是Guava库中的一个限流器,它提供如下功能:
- 基于PPS进行限流
- 基于PPS限流的同时提供热启动
下面是一段示例代码,它展示了如何创建一个RateLimiter,并且进行使用
final RateLimiter rateLimiter = RateLimiter.create(2.0); // rate is "2 permits per second"
void submitTasks(List tasks, Executor executor) {
for (Runnable task : tasks) {
rateLimiter.acquire(); // may wait
executor.execute(task);
}
}
可以看出,在创建RateLimiter时,设置了RateLimiter的PPS=2.0,
而之后每次执行一个任务之前,进行一次acquire(),
一次acquire消耗一个permit,
那么可以计算出任务的执行速度是 2个/秒
Permit是什么
在上文中提到了PPS(Permit per second),其中第一个P就是接下来要讲解的Permit。
Permit是什么?你可以把它理解为一个消耗单位:
- 如果要对QPS进行限制,那么Permit = Query,一次Query消耗一个Permit就能达到效果
- 如果对文件网络IO进行限制,那么Permit = Size of Package,每次包大小越大消耗的Permit越多
- 如果要对请求时长进行限制,那么Permit = Time Cost of Query
如下代码就是对网络IO进行限制,可以看出RateLimiter的PPS为5000,那么可以推断出
该程序的IO速度为 5000byte/s
final RateLimiter rateLimiter = RateLimiter.create(5000.0); // rate = 5000 permits per second
void submitPacket(byte[] packet) {
rateLimiter.acquire(packet.length);
networkService.send(packet);
}
如果让你实现一个RateLimiter,你如何实现?
如果仅考虑RateLimiter的第一个特性:
- 基于PPS进行限流
那么实现起来十分简单。
我们只需要记录上一个acquire执行的时间,用当前时间减去上一次执行的时间,获得一个Δt。
如果 > acquire消耗的Permit,则无需等待,否则等待 ( acquire消耗的Permit - Δt * PPS)/ PPS
上面这种实现虽然很简单,并且由于它只记录了上一次任务执行的时间,空间复杂度也很低。
但也由于只记录最近一次的执行时间,这种实现无法判断出当前系统是否处于缺少利用(underutilization)的状态。
做了再等
上面这种简单的实现还有一个问题,就是当一个acquire执行时,如果Permit不够,就需要等待,然而等待的过程中系统什么事儿也没干,这多浪费啊。不如学习如今的超前消费 ,先借用Permit,然后将还款日期作为执行时间计入内存。
缺少利用(underutilization)
当一个系统在近一段时间接受的请求(消耗的Permit数)远远小于 PPS,这个系统就处于缺少利用的状态。
比如进入深夜,用户请求减少,社区服务的QPS就减少了,因此处于缺少利用的状态。
缺少利用的状态,对于服务的处理能力是有很大影响的:
- 缺少利用,意味着系统的缓存命中率低,很多缓存都被淘汰了,因此此时执行效率也偏低,若QPS突然上升,可能无法承受。
- 缺少利用也意味着系统资源限制,比如buffer空置,就拿网络IO举例,当网络IO处于缺少利用的状态,网络缓冲区就是空的,那此时,网络IO的处理能力实际是更强的,因为刚来的请求可以马上写入缓冲区。
- 服务刚启动,也可以被看作处于缺少利用的状态,此时同样是处理效率偏低的(因为要进行很多初始化操作,而且缓存也是空的)
热启动(warm up)
对于上面描述的,关于缺少利用很有可能导致系统工作效率降低,如果系统面临突如其来的QPS增长,但概率会GG。因此为系统预留一段时间,逐步去提升QPS,成为了一个对抗策略,我们把它叫做热启动。
实现热启动
要实现热启动,我们需要引入一个变量storedPermits,通过这个变量可以来描述系统的利用状态。
storedPermits从字面上看就是,被存储的permit。
在之前的实现方法中,permit没被使用完直接就被扔掉,而现在如果permit没被使用完,则被加在storedPermits中,则如果storedPermits也多,则系统越空闲,而storedPermits越小则表明系统越繁忙。
现在当我们需要处理一个acquire时,storedPermits越大则需要等待的时间越长,而storedPermits越低,这越接近我们的PPS,在RateLimiter中使用storedPermitsToWaitTime方法来计算等待时间
storedPermitsToWaitTime
storedPermitsToWaitTime第一个规则是,有storedPermits就使用storedPermits,没有或不够再使用fresh Permits(即更新的Permits)
Fresh Permits消耗的时间 = stable interval * count(Fresh Permits)
Stable Interval(稳定状态下一个Permit需要消耗的时间间隔)= 1 / PPS
*
* ^ throttling
* |
* cold + /
* interval | /.
* | / .
* | / . <-- "warmup period" is the area of the trapezoid between
* | / . thresholdPermits and maxPermits
* | / .
* | / .
* | / .
* stable +----------/ WARM .
* interval | . UP .
* | . PERIOD.
* | . .
* 0 +----------+-------+--------------> storedPermits
* 0 thresholdPermits maxPermits
而storedPermits消耗的时间如何计算呢?
那就要参考上图了,我先介绍一下上图的一些参数:
- Stable Interval ,稳定状态下一个Permit需要等待的时间,它等于 1 / PPS
- Cold Interval,极度缺乏利用状态下一个Permit需要等待的时间, Cold Interval = Stable Interval * Cold Factor
- Cold Factor,可配置参数
- thresholdPermits,当storedPermits超过这个预置,等待时间将会发生变化
- maxPermits,最大的storedPermits
- warmup period,热启动时长,可配置,它是对图中函数进行[thresholdPermits,maxPermits]的积分
其中有
- Cold Interval = Stable Interval * Cold Factor
- Stable Interval * thresholdPermits = 0.5 * warmup period,没有为什么,就这样规定的
- warmup period = (Stable Interval + Cold Interval)* (maxPermits - thresholdPermits)* 0.5
- maxPermits = thresholdPermits + 2 * warmupPeriod / (stableInterval + coldInterval).
当我们需要使用storedPermits,
就对我们要消耗的storedPermits对如上图函数做积分就能获得。
那么使用RateLimiter进行热启动时,(QPS/t)的图像应该是什么样的?
首先,已知throttling和stormPermits之间的关系
throttling = 1/QPS = t / q
stormPermits = maxPermits - q
我们实际上只要求出红色虚线范围内QPS/t的图像就OK了
但是由于
stormPermits = maxPermits - q,而我们要对q进行分析,因此先对图像进行反转
为了计算简单,我们假设这根直线的方程是 f(q) = t/q = -ax + b
其中a,b都大于0
那么我们先对f(q)求积分
integral f(q) = -a/2 * q^2 + bq = t
对f(q)求积分自然是等于t的
然后我们用t来表示q
q = (2b [-/+] sqrt(4b^2 - 4at))/ 2a = g(t)
然后我们对g(t)求导
g'(t) = -1 / (sqrt(4b^2 - 4a*t)) = q / t = qps