html做的小网站,苏州保洁公司哪家好,打网站显示域名解析错误,宝塔面板建设网站前言
相信大家对于谷歌RateLimiter一定并不陌生,在项目中应该也经常拿来进行限流#xff0c;但是对于其实现原理并不一定能用熟于心#xff0c;本文带大家从源码探究RateLimiter的设计与具体实现。
RateLimiter的组成 从源码可以看到#xff0c;RateLimiter由stopwatch与m…前言
相信大家对于谷歌RateLimiter一定并不陌生,在项目中应该也经常拿来进行限流但是对于其实现原理并不一定能用熟于心本文带大家从源码探究RateLimiter的设计与具体实现。
RateLimiter的组成 从源码可以看到RateLimiter由stopwatch与mutexDoNotUseDirectly组成先简单了解其分别的作用如下
stopwatch计时器的作用.mutexDoNotUseDirectly主要通过锁解决并发问题本文暂不叙述此块感兴趣的同学可以留言。
源码分析 上图展示了RateLimite的类图可以看到其有一个子类SmoothRateLimiter在往下看SmoothRateLimiter中有两个实现类SmoothBursty与SmoothWarmingUp分别表示两种限流的不同场景SmoothBursty是我们常见的关于限流算法中令牌桶算法的一个实现通过固定速率生成令牌当流量进入时申请令牌令牌充足时则直接获取成功不充足时返回等待时间而SmoothWarmingUp与SmoothBursty不同的是SmoothWarmingUp在固定速度的基础上增加了预热流程可以更好的应对突发流量。 另外在初始化和小流量时更慢得进行流量得提供也符合实际的应用场景本文主要讲述常用SmoothBursty的实现。
为了便于理解我们从最简单限流程序开始一步一部理解RateLimiter的设计与实现。
1.RateLimiter创建 可以看到RateLimiter创建分为两步首先创建RateLimiter的实现类SmoothBursty对象然后setRate设置限流器的控制速率。 首先我们看下SmoothBursty的实现其首先创建了SleepingStopwatch类stopwatch对象。 stopwatch中初始elapsedNanos 0 startTick 765333275998400,其有一个sleepMicrosUninterruptibly方法,释义如下
elapsedNanos经过的时间单位为纳秒startTick开始时间sleepMicrosUninterruptibly(long micros)实现了不可中断的不可中断的sleep(用于令牌不足时限流等待)
紧接着其传入stopwatch与maxBurstSeconds创建一个SmoothBursty对象SmoothBursty继承至SmoothRateLimiter其额外定义了一个maxBurstSeconds变量SmoothRateLimiter继承至RateLimiter是RateLimiter抽象类的具体实现其中有四个变量我们同maxBurstSeconds一起进行解释
SmoothRateLimiter.storedPermits实际预存的许可(即令牌)SmoothRateLimiter.maxPermits最大的许可数(即令牌)SmoothRateLimiter.stableIntervalMicros每产生一个令牌需要消耗的微秒数SmoothRateLimiter.nextFreeTicketMicros初始值为0L表示下一个令牌可用的时间戳SmoothBursty.maxBurstSeconds初始值为1.0D表示桶中最多可以保存多少秒存入的令牌数 从上图可以看到RateLimiter创建后开始setRate传入的permitsPerSecond设置限流速率
permitsPerSecond:令牌数/每秒钟即我们期望限制的qps. 传入的nowMicros当前值为1030409545nextFreeTicketMicros初始为0此步骤计算赋值了当前存储的令牌数量storedPermits与 nextFreeTicketMicros nowMicros(1030409545) 然后根据传入的permitsPerSecond设置了产生一枚令牌需要的时间stableIntervalMicros。 接着起开始按比例更新当前存储的令牌数量可以看到初始令牌数量为0时其首次创建时存储的令牌数量即为0.0, maxPermits maxBurstSeconds * permitsPerSecond 1.0 至此RateLimiter的初始创建结束下面我们从最简单也是日常使用最多的方法acquire()看看其如何通过上述各个变量控制限流。为了方便理解下图展示了当前RateLimiter的组成。 2.RateLimiter.acquire()控制限流 还是从源码入手可以看到acquire()实际调用的方法acquire(1)即当前需要获取1块令牌其实现分为3个步骤
计算需要等待的时间microsToWaitstopwatch.sleepMicrosUninterruptibly(microsToWait)进行阻塞等待。返回等待时间 从第1步开始看传入令牌数与当前时间nowMicros 2322440641 由于当前令牌数量足够计算出momentAvailable 0即无需阻塞等待 且将nextFreeTicketMicro等于当前时间nowMicros后则可以推测出下次计算时nowMicros必然大于nextFreeTicketMicros此时无需等待。
这是因为nowMicros nextFreeTicketMicros 时此间产生令牌数量 当前持有的令牌数量 一定大于 最大的令牌数量而最大的令牌数量大于请求的令牌数量所以请求无需限流阻塞等待。
而当并发请求数变多导致某一时刻持有的令牌数量不足时则会发生限流阻塞等待为了方便分析我们通过限流设置为1qps,通过单词请求1000000000个令牌数模拟高并发场景。 可以看到初次请求时nowMicros nextFreeTicketMicros满足此时令牌数量为1而超过的令牌数量为refreshPermits 99999999通过计算需要99999999000000的间隔时间才能产生这么多令牌而此时注意了返回值为上一次(这里初始请求的上一次即初始值为0)的nextFreeTicketMicros 0然后将本次请求的nextFreeTicketMicros增加99999999000000而最终计算出的等待时间为Math.max(momentAvailable - nowMicros, 0L) 0.实际并没有产生等待而在下一次请求时如下图可以看到此时nowMicros nextFreeTicketMicros, 此时说明还未到令牌释放的时间需要等待Math.max(momentAvailable - nowMicros, 0L) 0, 可以看到本次请求等待的时间其实时上次请求时超出的令牌数需要等待的时间继续往下执行你就会发现RateLimiter每次请求的超支的令牌等待时间都是在下一次执行时进行等待。 结语
SmoothBrusty的设计遵循令牌桶的思路SmoothBursty以指定的速率生成许可当一个请求申请获取许可时如果当前许可数满足申请数量则消耗掉许可直接返回无需等待。当当前许可数小于申请数量时会计算多余部分许可需要等待生成的时间更新下一次许可可发放的时间但值得注意的是尽管已经消耗掉所有的许可并且不够总请求数量本次请求也并不会阻塞等待而是将阻塞等待放到下一个请求说明此处可以支持突发流量。这里的设计其实还是蛮巧妙的。比如一些突发流量场景当前瞬发的高流量请求可快速返回无需阻塞而后续请求可能相隔很久则请求时不会等待从而提高系统整体的响应速率当然这在某些场景可能会导致qps超标存在造成系统崩溃风险这里我们主要了解其设计原理放才能在合适场景合理使用以及规避风险。
