限流之固定窗口/滑动窗口计数法理解

最新推荐文章于 2024-07-29 09:58:03 发布

legend050709ComeON

最新推荐文章于 2024-07-29 09:58:03 发布

阅读量4.4k

点赞数 7

分类专栏：网络限速

原文链接：https://juejin.cn/post/6870396751178629127

版权

网络限速专栏收录该内容

6 篇文章 5 订阅

订阅专栏

背景

分布式系统中，由于接口API无法控制上游调用方的行为，因此当瞬时请求量突增时，会导致服务器占用过多资源，发生响应速度降低、超时、乃至宕机，甚至引发雪崩造成整个系统不可用。
限流，Rate Limiting，就是对API的请求量进行限制，对于超出限制部分的请求作出快速拒绝、快速失败、丢弃处理，以保证本服务以及下游资源系统的稳定。

哪些原因会带来瞬时请求量突增？

热点业务、突发热点数据带来的激增。例如微博热搜的爆点。
上游系统的bug导致。
恶意的攻击流量。

实现限流的方法很多，一句话来讲，就是限制每秒钟内API可处理的请求量。常见的有以下几种算法：固定窗口计数法、滑动窗口计数法、漏桶算法、令牌桶算法。

固定窗口(Fixed Window)计数法

原理

计数器固定窗口算法原理图

固定窗口计数法的思路是：

将时间划分为固定的窗口大小，例如1s
在窗口时间段内，每来一个请求，对计数器加1。
当计数器达到设定限制后，该窗口时间内的之后的请求都被丢弃处理。
该窗口时间结束后，计数器清零，从新开始计数。如上图所示，10s内限制1000个请求，在第11s的时候计数器会从0重新开始计数。

特点

优点：实现简单，并且内存占用小，我们只需要存储时间窗口中的计数即可;

缺点：流量曲线可能不够平滑，有“突刺现象”（2N），如下图所示。

计数器固定窗口算法限流曲线

一段时间内（不超过时间窗口）系统服务不可用。

比如窗口大小为1s，限流大小为100，然后恰好在某个窗口的第1ms来了100个请求，然后第2ms-999ms的请求就都会被拒绝，这段时间用户会感觉系统服务不可用。

窗口切换时可能会产生两倍于阈值流量的请求。即：瞬时流量的临界问题，在最坏的情况下，会让通过的请求量是限制数量的两倍；

比如窗口大小为1s，限流大小为100，然后恰好在某个窗口的第999ms来了100个请求，窗口前期没有请求，所以这100个请求都会通过。再恰好，下一个窗口的第1ms有来了100个请求，也全部通过了，那也就是在2ms之内通过了200个请求，而我们设定的阈值是100，通过的请求达到了阈值的两倍。

计数器固定窗口限流算法产生两倍于阈值流量的请求

实现

public class CounterRateLimiter extends MyRateLimiter {
    /**
     * 每秒限制请求数
     */
    private final long permitsPerSecond;
    /**
     * 上一个窗口的开始时间
     */
    public long timestamp = System.currentTimeMillis();
    /**
     * 计数器
     */
    private int counter;

    public CounterRateLimiter(long permitsPerSecond) {
        this.permitsPerSecond = permitsPerSecond;
    }

    @Override
    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        // 窗口内请求数量小于阈值，更新计数放行，否则拒绝请求
        if (now - timestamp < 1000) {
            if (counter < permitsPerSecond) {
                counter++;
                return true;
            } else {
                return false;
            }
        }
        // 时间窗口过期，重置计数器和时间戳
        counter = 0;
        timestamp = now;
        return true;
    }
}