遗传信号率算法在漏桶算法上的优势

Question

我正在寻找一种速率限制传入请求到REST HTTP服务器的算法。我已经完成了＆＃34; Leaky Bucket＆＃34; ＆安培; ＆＃34;通用信元速率算法：虚拟Schedulling＆＃34;

根据我的理解，Leaky Bucket具有以下限制： -

1. 如果队列/存储桶为空并且请求在时钟滴答之前（当我们实际处理请求时），则请求必须等待时间直到时钟滴答。
2. 网络域中的可变长度数据包

我已经完成了blog，它实现了＆＃34;通用信元速率算法：虚拟Schedulling＆＃34;。

有些人可以解释一下： -

1. GCRA如何解决＃1中提到的漏桶的限制？
2. 在我的使用案例中，如果我将时钟滴答设置为低（可能每纳秒检查一次），不应该减少Leaky Bucket的问题吗？

Answer 1

漏桶算法有两种变体，meter和queue。仪表1在这里更相关，所以让我们关注它。

这个想法是为桶分配一个滴速（在桶之间统一，或者基于某些层）。进来的工作有一些＆＃34;音量＆＃34;与之相关联。它可以装入水桶或不装入水桶。如果没有，则将其丢弃。如果它适合，则将其传递以进行处理（至少在仪表版本中）。

谁负责滴水桶？您提到的博客声称这通常是通过后台进程完成的，后台进程在存储桶中循环并滴下它们。它提到了一个缺点，即如果它可以处理桶的速率很低（极端情况下它会脱机），可能会丢弃一个作业而不是因为没有足够的空卷属于桶，而是因为滴水过程只是没有更新它。这基本上是你的观点1;我没有看到你的观点2的问题（虽然你可能已经阅读了一个关于统一卷的数量不足的泄漏桶版本之一的描述，但算法没有固有的要求）。 p>

GCRA进来的地方。如果你考虑一下，单独的滴水过程并不是必需的。如果您根据存储桶跟踪当前状态和作业，则可以计算下一次任何给定的未来作业大小的空容量。因此，当一份工作到来时，它只是检查它是在此时间之前还是之后。如果它之前，它被丢弃。如果它被发现，它将被通过，并且更新时间直到下一个作业。

关于您的问题（相关）：

1. 由于GCRA不依赖于单独的滴水过程，因此您不会遇到问题，因为它已经死亡或者无法跟上。这导致了下一点：特别是

2. 如果你以非常高的频率运行单独的过程，那么，只要滴水过程保持不变，一切都很好。但是，频率很高，滴水过程无法跟上。

请注意，没有免费午餐。无论您拥有多少处理能力，都需要检查空体积并更新滴水。因人而异。对于某些设置和实现，很容易想象一个单独的滴水过程（假设有人设计好系统，并且它不会脱机），使系统具有整体更低的延迟，更高的吞吐量，或者都。其他设置和实现可能正好相反。