令牌桶与固定窗口(流量突发)
Posted
技术标签:
【中文标题】令牌桶与固定窗口(流量突发)【英文标题】:Token bucket vs Fixed window (Traffic Burst) 【发布时间】:2021-04-28 06:50:05 【问题描述】:我在比较令牌桶和固定窗口限速算法,但对这两种算法的流量突发有点混淆。
假设我想将流量限制为 10 个请求/分钟。
在令牌桶中,令牌以每分钟 10 个令牌的速度添加。
Time Requests AvailableTokens
10:00:00 0 10 (added 10 tokens)
10:00:58 10 0
10:01:00 0 10 (added 10 tokens)
10:01:01 10 0
现在,如果我们在时间戳 10:01:01 看到,在最后一分钟允许了 20 个请求,超过了我们的限制。
同样,使用固定窗口算法。 窗口大小:1 分钟。
Window RequestCount IncomingRequests
10:00:00 10 10 req at 10:00:58
10:01:00 10 10 req at 10:01:01
这里也有类似的问题。
这两种算法是否都存在这个问题,还是我的理解存在差距?
【问题讨论】:
这里here 应该回答你的大部分问题,而且比这里的答案要详细得多。简而言之,在 Token bucket 中,上述场景不应该发生/可以预防,尽管还有其他问题。在固定窗口的情况下,双倍率问题可能完全按照您描述的方式发生,因此要消除这种可能性,您需要将速率设置为 N/2,其中 N 是您想要的最大速率。 我之前浏览过此链接,但找不到我所关心的问题的答案。我的理解是为了防止令牌桶中的这个问题,我们必须优化桶的大小,因为它定义了可以提供的最大突发流量。但这类似于在固定窗口中将速率从 N 降低到 N/2。 @shamis 您提供的链接实现了带有时间戳概念的令牌桶,因此它包括某种形式的滑动窗口方法,该方法不适用于普通令牌桶方法的这个问题。 【参考方案1】:我对这些算法也有同样的困惑。
令牌桶的诀窍在于桶大小(b) 和再填充率(r) 不必相等。
对于您的特定示例,您可以将存储桶大小设置为 b = 5,再填充率 r = 1/10(每 10 秒 1 个令牌)。
在此示例中,客户端仍然能够每分钟发出 11 个请求,但这已经少于示例中的 20 个,并且它们会随着时间的推移而分散。而且我还相信,如果您使用这些参数,您可以在根本不允许超过 10 个请求/分钟的情况下实现策略。
Time Requests AvailableTokens
10:00:00 0 5 (we have 5 tokens initially)
10:00:10 0 5 (refill attempt failed cause Bucket is full)
10:00:20 0 5 (refill attempt failed cause Bucket is full)
10:00:30 0 5 (refill attempt failed cause Bucket is full)
10:00:40 0 5 (refill attempt failed cause Bucket is full)
10:00:50 0 5 (refill attempt failed cause Bucket is full)
10:00:58 5 0
10:01:00 0 1 (refill 1 token)
10:01:10 0 2 (refill 1 token)
10:01:20 0 3 (refill 1 token)
10:01:30 0 4 (refill 1 token)
10:01:40 0 5 (refill 1 token)
10:01:49 5 0
10:01:50 0 1 (refill 1 token)
10:01:56 1 0
其他选项:
b = 10 和 r = 1/10 b = 9 和 r = 1/10【讨论】:
很好的答案!是否有一个方程显示给定 b 和 r 的最大速率? 如果您询问突发大小,那么来自***的这句话可能是一个答案。 T:爆发时间。 M:吞吐量。 B:突发大小。 T = b / (M - r) 如果 (r以上是关于令牌桶与固定窗口(流量突发)的主要内容,如果未能解决你的问题,请参考以下文章