1 何谓限流
限流,顾名思义,便是限制流量的意思。系统规定在一段时间内只能进入这么多的流量,如果超过限额的话,那就不好意思了,我这个系统接受不了。通过限流算法,我们可以控制系统的 qps,更好地对系统提供保护。
本文致力于介绍几种我们常用的限流算法,同时会对其原理进行一定程度的剖析,希望大家能有所收获。
2 计数器算法
算法原理
计数器算法是最简单的限流算法,假设我们规定 A 接口在1小时之内的访问次数不能超过1000次,我们可以在开始时设置一个计数器,只有有一个请求进来,计数器的值就加一。如果计数器的值大于1000,而且该次请求与第一次请求的间隔时间小于1小时,说明请求过多,需要执行拒绝策略;如果该次请求与第一次请求的间隔时间大于1小时,直接重置计数器即可。
存在的问题
该算法虽然比较简单,但是存在一个临界问题。
假设存在一个恶意用户,在第一个小时的最后一秒发送了1000个请求,又在第二个小时的第一秒再次发送了1000个请求,通过在时间窗口的重置节点处突发请求,瞬间超过我们的速率限制。恶意用户可能通过这个算法的漏洞,在一个较短的时间内制造大量的流量,来压垮我们的应用。
实现方法
使用 redis 的 incr 原子自增性。
3 滑动窗口算法
算法原理
计数器算法由于其存在的临界问题,统计的精度过低,可能在时间窗口的重置节点处接收大量流量,为解决这个问题,我们引入了滑动窗口算法。
我们依然使用上面的例子,把一个时间窗口设置为1小时,然后我们再对时间窗口进行划分。例如,我们把时间窗口划分为60格,即每一分钟代表一格,每过一分钟,时间窗口都会往右滑动一格,每一格都有自己的计数器。
对临界问题的解决
我们上面探讨过这个一个情节,一个恶意用户在第一个小时的最后一秒发送了1000个请求,又在第二个小时的第一秒再次发送了1000个请求。在滑动窗口算法中,最后一秒到达的1000个请求会在一个格子中,第一秒到达的1000的请求会在一个格子中,当新的一分钟到来时,时间窗口会向右移动一格,时间窗口的总请求数量一定超标(因为时间窗口包括了最近的这两个格子,这时至少有2000个请求),所以触发限流操作。
计数器算法其实就是只有一格的滑动窗口算法,当滑动窗口算法的格子划分越多,限流的统计就越精确。
4 令牌桶算法
请求在被处理之前,需要首先获取一个令牌,才能执行接下来的业务逻辑,处理完业务逻辑需要将令牌删除。令牌桶是一个存放令牌的地方,它会根据限流大小,会按照一定的速率向桶中添加令牌。
令牌桶会设置最大的放置令牌限制,当令牌桶满了,新添加的令牌会被直接丢弃;令牌桶也有最低限额,当令牌数到达最低限额时,请求处理完之后将不会删除令牌。
5 漏桶算法
所谓漏桶,顾名思义,便是一个漏水的桶,我们往这个桶加水的速率可能是任意的,但桶漏水的速度是必然恒定的。如果流入水的速率过快,已经超过桶的容量大小,那水便会直接流出(被丢弃)。漏桶算法便是在此基础上设计的。
所谓漏桶算法,便是当访问请求到达时,直接放置进入漏桶,如漏桶当前容量已到达限流上限,则触发限流策略。漏桶会以固定的速率释放访问请求,直到漏桶为空。
6 聊聊令牌桶算法与漏桶算法的区别
漏桶算法可以限制数据的平均传输速率,而令牌桶算法除了能够限制数据的平均传输速率外,还能够允许某种程度的突发传输。因为在令牌桶算法中,只要令牌桶中存在令牌,那么就允许突发地传输数据直到达到用户配置的门限,所以它适合于具有突发特性的流量。
参考:三种常见的限流算法