[系统设计Alex Xu] 限流器 Rate Limiter 学习笔记-中

限流算法

主要有以下5种算法，各有利弊。

令牌桶算法
漏桶算法
固定窗口计数器
滑动窗口log
滑动窗口计数器

令牌桶算法

令牌桶算法被广泛用于速率限制。它简单易懂，是互联网公司普遍采用的算法。亚马逊和Stripe都使用这个算法来限制他们的API请求。令牌桶算法的工作原理如下：

令牌桶是一个具有预定义容量的容器。令牌按照预设速率定期放入桶中。一旦桶满了，就不再添加令牌。如下图所示，令牌桶容量为4。填充器每秒将2个令牌放入桶中。一旦桶满，额外的令牌将溢出。

每个请求消耗一个令牌。当请求到达时，我们检查令牌桶中是否有足够的令牌。下图解释了它是如何工作的。 • 如果有足够的令牌，我们为每个请求取出一个令牌，然后请求继续。 • 如果没有足够的令牌，请求将被丢弃。

下图展示了令牌如何消费，重填以及限流的逻辑。下面的案例中，令牌桶大小为4，重填率是1分钟4个。

令牌桶算法需要两个参数：

• 桶的大小：桶中允许的令牌最大数量

• 补充速率：每秒放入桶中的令牌数量我们需要多少个令牌桶？这取决于速率限制规则，因此会有所不同。以下是一些例子：

• 通常需要为不同的API端点使用不同的令牌桶。例如，如果允许用户每秒钟发1篇帖子、每天添加150个朋友和每秒钟点赞5次，则每个用户需要3个桶。 • 如果我们需要基于IP地址限制请求速率，则每个IP地址都需要一个桶。 • 如果系统允许最多每秒10,000个请求，则最好拥有一个全局桶，供所有请求共享。

优点： • 该算法易于实现。 • 存储空间使用效率高。 • 令牌桶允许在短时间内进行短暂的流量突发。只要令牌没有用完，请求就可以继续通过。

缺点： • 算法中的两个参数是桶大小和令牌补充速率。然而，适当地调整它们可能会具有挑战性

漏桶算法

和令牌桶很像，可以理解为加了一个水龙头，以固定速率流出。本质上就是加了一个先进先出的队列，队列下游负责处理请求。可以想象Java中ThreadPool中的队列。流程如下：

如果队列满了，直接扔掉请求。

否则入队列，等待处理。

漏桶算法同样有两个参数：

桶大小：其实就是队列大小
处理速率

Shopify这家公司就用了这个算法。

优点：队列空间大小有限，可以节省内存；另外固定的处理速率很适合一些需要稳定处理的场景

缺点：面临突发流量，如果queue里有old 请求，突发请求可能会被drop掉。另外就是两个参数不是那么容易就能调整好。

固定窗口计数器算法

算法工作如下：

• 算法将时间线分成固定大小的时间窗口，并为每个窗口分配一个计数器。

• 每个请求将计数器增加一。

• 一旦计数器达到预定义的阈值，新请求将被丢弃，直到一个新的时间窗口开始。让我们用一个具体的例子来看看它是如何工作的。

在下图中，时间单位为1秒，系统允许每秒最多3个请求。在每秒的窗口中，如果收到超过3个请求，则会丢弃额外的请求。

这个算法一个比较大的问题是，如果突发流量出现在上一个窗口end和下一个窗口start，会导致超过limit的请求通过。如图所示

上图里面，每分钟最大请求设为5，2:00:58进来3个请求，2:00:59 进来2个。2:01:01进来一个，2:01:02进来4个。在这个不到1min的时间段内就有10个请求通过，比设定的大一倍。

优点：内存小，容易理解，每过单位时间就reset适合特定场景

缺点：上图所示，突发流量可能导致比预设更多的请求通过。

滑动窗口log算法

为了解决固定窗口算法的问题，滑动窗口log算法出现了，解决办法如下：

• 该算法会跟踪请求的时间戳。时间戳数据通常存储在缓存中，例如 Redis 的sorted set

• 当一个新的请求进来时，删除所有过时的时间戳。过时的时间戳被定义为早于当前时间窗口开始时间的时间戳

• 将新请求的时间戳添加到日志中

• 如果日志大小等于或小于允许的计数，则接受请求。否则，该请求被拒绝。

假如每分钟设定2个请求，图1请求允许。

图2请求在1:00:30也被允许，目前计数为2，没有超过limit；

图3请求1:00:50 不被允许，因为加进来计数为3，超过limit；

图4请求1:01:40 被允许，因为在[1:00:40, 1:01:40)范围内请求数量在limit以内。同时移除掉过时的请求。

优点：限流非常精确，在任意的滑动窗口里，都不会超过limit（注意和固定窗口对比）

缺点：耗内存，被drop掉的请求也被存在了内存里，想象一下DDoS打过来会怎么样

滑动窗口计数算法

滑动窗口计数算法是一种混合方法，结合了固定窗口计数器和滑动窗口log。该算法可以通过两种不同的方法实现。本节将介绍一种实现方法，并在本节末尾提供另一种实现的参考。下图说明了该算法的工作原理。

假设速率限制器允许每分钟最多7个请求，在前一分钟有5个请求，在当前分钟有3个请求。对于到达当前分钟30%位置的新请求，使用以下公式计算滚动窗口中的请求数量：

• 当前窗口中的请求+上一个窗口中的请求*滚动窗口和前一个窗口的重叠百分比

• 使用这个公式，我们得到3 + 5 * 0.7% = 6.5个请求。根据使用情况，数量可以四舍五入为整数或小数。在我们的例子中，它被四舍五入为6。由于速率限制器允许每分钟最多7个请求，所以当前请求可以通过。然而，在接收到另一个请求后，限制将被达到。

优点： • 它可以平滑流量峰值，因为速率是基于前一个窗口的平均速率计算的。 • 内存效率高。

缺点： • 它仅适用于不太严格的回溯窗口。它是实际速率的近似值，因为它假设前一个窗口中的请求是均匀分布的。然而，这个问题可能并没有看起来那么严重，根据Cloudflare的实验，在4亿个请求测试中，只有0.003%的请求被错误的允许。