Java常见限流方式

1、计数限流

例如系统能同时处理 100 个请求,保存一个计数器,处理了一个请求,计数器就加一,一个请求处理完毕之后计数器减一。

每次请求来的时候看看计数器的值,如果超过阈值就拒绝。

非常简单粗暴,计数器的值要是存内存中就算单机限流算法。

如果放在第三方存储里,例如 Redis 中,集群机器访问就算分布式限流算法。

优点就是:简单粗暴,单机在 Java 中可用 Atomic 等原子类、分布式就 Redis incr。

缺点就是:假设我们允许的阈值是1万,此时计数器的值为 0, 当 1 万个请求在前 1 秒内一股脑儿的都涌进来,这突发的流量可是顶不住的。

缓缓地增加流量处理和一下子涌入对于程序来说是不一样的。
图片

计数器限流伪代码实现
而且一般的限流都是为了限制在指定时间间隔内的访问量,因此还有个算法叫固定窗口。

2、固定窗口限流

它相比于计数限流主要是多了个时间窗口的概念,计数器每过一个时间窗口就重置。规则如下:

请求次数小于阈值,允许访问并且计数器 +1;
请求次数大于阈值,拒绝访问;
这个时间窗口过了之后,计数器清零;
在这里插入图片描述

固定窗口限流伪代码实现
看起来好像很完美,实际上还是有缺陷的。

固定窗口临界问题
假设系统每秒允许 100 个请求,假设第一个时间窗口是 0-1s,在第 0.55s 处一下次涌入 100 个请求,过了 1 秒的时间窗口后计数清零,此时在 1.05 s 的时候又一下次涌入100个请求。

虽然窗口内的计数没超过阈值,但是全局来看在 0.55s-1.05s 这 0.1 秒内涌入了 200 个请求,这其实对于阈值是 100/s 的系统来说是无法接受的。

![图片](https://img-blog.csdnimg.cn/611cef1816e14c028cb3ede4651355f2.png

为了解决这个问题引入了滑动窗口限流。

3、滑动窗口限流

滑动窗口限流解决固定窗口临界值的问题,可以保证在任意时间窗口内都不会超过阈值。

相对于固定窗口,滑动窗口除了需要引入计数器之外还需要记录时间窗口内每个请求到达的时间点,因此对内存的占用会比较多。

规则如下,假设时间窗口为 1 秒:

记录每次请求的时间
统计每次请求的时间 至 往前推1秒这个时间窗口内请求数,并且 1 秒前的数据可以删除。
统计的请求数小于阈值就记录这个请求的时间,并允许通过,反之拒绝。
图片
图片
但是滑动窗口和固定窗口都无法解决短时间之内集中流量的突击。

我们所想的限流场景是:

每秒限制 100 个请求。希望请求每 10ms 来一个,这样我们的流量处理就很平滑,但是真实场景很难控制请求的频率,因此可能存在 5ms 内就打满了阈值的情况。

当然对于这种情况还是有变型处理的,例如设置多条限流规则。不仅限制每秒 100 个请求,再设置每 10ms 不超过 2 个。

再多说一句,这个滑动窗口可与TCP的滑动窗口不一样。

TCP的滑动窗口是接收方告知发送方自己能接多少“货”,然后发送方控制发送的速率。

接下来再说说漏桶,它可以解决时间窗口类的痛点,使得流量更加平滑。

4、漏桶算法

如下图所示,水滴持续滴入漏桶中,底部定速流出。

如果水滴滴入的速率大于流出的速率,当存水超过桶的大小的时候就会溢出。

规则如下:

请求来了放入桶中
桶内请求量满了拒绝请求
服务定速从桶内拿请求处理
图片

在这里插入图片描述

可以看到水滴对应的就是请求。

它的特点就是宽进严出,无论请求多少,请求的速率有多大,都按照固定的速率流出,对应的就是服务按照固定的速率处理请求。

“他强任他强,老子尼克杨”。

看到这想到啥,是不是和消息队列思想有点像,削峰填谷。

一般而言漏桶也是由队列来实现的,处理不过来的请求就排队,队列满了就开始拒绝请求。

看到这又想到啥,线程池不就是这样实现的嘛?

经过漏洞这么一过滤,请求就能平滑的流出,看起来很像很挺完美的?实际上它的优点也即缺点。

面对突发请求,服务的处理速度和平时是一样的,这其实不是我们想要的。

在面对突发流量我们希望在系统平稳的同时,提升用户体验即能更快的处理请求,而不是和正常流量一样,循规蹈矩的处理(看看,之前滑动窗口说流量不够平滑,现在太平滑了又不行,难搞啊)。

而令牌桶在应对突击流量的时候,可以更加的“激进”。

5、令牌桶算法

令牌桶其实和漏桶的原理类似,只不过漏桶是定速地流出,而令牌桶是定速地往桶里塞入令牌,然后请求只有拿到了令牌才能通过,之后再被服务器处理。

当然令牌桶的大小也是有限制的,假设桶里的令牌满了之后,定速生成的令牌会丢弃。

规则:

定速的往桶内放入令牌
令牌数量超过桶的限制,丢弃
请求来了先向桶内索要令牌,索要成功则通过被处理,反之拒绝
在这里插入图片描述
看到这又想到啥?Semaphore 信号量啊,信号量可控制某个资源被同时访问的个数,其实和咱们拿令牌思想一样,一个是拿信号量,一个是拿令牌。

只不过信号量用完了返还,而咱们令牌用了不归还,因为令牌会定时再填充。

再来看看令牌桶的伪代码实现,可以看出和漏桶的区别就在于一个是加法,一个是减法。

在这里插入图片描述
可以看出令牌桶在应对突发流量的时候,桶内假如有 100 个令牌,那么这 100 个令牌可以马上被取走,而不像漏桶那样匀速的消费。所以在应对突发流量的时候令牌桶表现的更佳。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值