tuk*_*tuk 5 algorithm rate-limiting bucket
我正在寻找一种用于限制 REST HTTP 服务器传入请求速率的算法。我已经完成了“漏桶”和“通用信元速率算法：虚拟调度”
据我了解，漏桶有以下局限性：-
我浏览过这个实现“通用信元速率算法：虚拟调度”的博客。
有人可以向我解释以下内容吗：-
漏桶算法有两种变体：meter和queue。仪表一在这里更相关，所以让我们重点关注它。
这个想法是为一个桶分配一个滴水率（或者在桶之间统一，或者基于某个层）。进来的工作有一些与之相关的“数量”。它可以放入桶中，也可以不放入桶中。如果不符合，则将其丢弃。如果适合，则将其传递以进行处理（至少在仪表版本中）。
谁负责滴水桶？您提到的博客声称这通常是由后台进程完成的，该进程在水桶周围循环并滴水。它提到了缺点，如果它处理桶的速率很低（极端情况是离线），作业可能会被丢弃，不是因为没有足够的空容量属于桶，而是因为滴水进程只是没有更新它。这基本上就是你的第一点；我没有看到你的第 2 点的问题（尽管你可能已经阅读了无数版本的漏桶之一的描述，该版本受限于统一的体积，但该算法固有的任何内容都不需要这样做）。
这就是 GCRA 的用武之地。如果您仔细想想，实际上并不需要单独的滴水过程。如果您跟踪每个存储桶的当前状态和作业进入，您可以计算出下一次对于任何给定的未来作业大小将有足够的空卷。因此，当作业到达时，它只是检查它是在这个时间之前还是之后到达的。如果它之前出现过，则将其丢弃。如果它晚于，则允许通过，并且更新下一个作业之前的时间。
关于您的问题（相关）：
由于使用 GCRA，您不依赖于单独的滴水过程，因此您不会遇到死机或无法跟上的问题。这引出了下一点：特别是，
如果您以非常高的频率运行单独的进程，那么，只要滴水过程保持不变，一切都很好。然而，如果频率较高，滴水过程可能会跟不上。
但请注意，天下没有免费的午餐。无论您拥有什么处理能力，都需要有人检查空容量并更新滴注。YMMV。对于某些设置和实现，很容易想象一个单独的滴水过程（假设有人很好地设计了系统，并且它不会离线）可以为系统提供整体更低的延迟、更高的吞吐量或两者兼而有之。其他设置和实现可能有相反的情况。