并发与速率限制

Question

我们计划为我们的基于休息的框架实施速率限制器。但是我有点困惑要实现哪一个，在并发和速率限制之间哪一个更重要。我发现在大多数地方，例如 apachecamel 人们已经实施了速率限制而不是并发。但在我看来，速率限制实际上几乎没有意义，相反，并发是我们面对多个并发请求的服务总是需要的？请让我知道您对此的看法。

Answer 1

如果您正在销售 API 并希望维护特定的价格模型，则速率限制可能最有用。

对于弹性用例（例如保护 API 免于过载），我会说并发限制更有意义，因为它对系统中的更改更灵活，并提供了一种实现背压的简单方法。

为了说明，这里有一个例子：

服务器 S1 可以处理 10 EPS（每秒事件数）的速率。为了安全起见，您决定将调用它的速率限制为 8 EPS。现在 S1 开始出现一些问题（例如，开发人员使代码性能降低、磁盘问题等）并且只能处理 5 个 EPS。使用相同的速率限制，您将继续敲击 S1，它最终会死亡。

相反，您可以使用Little 定律计算等效并发限制。如果您的平均延迟为 0.5 秒，则 8 EPS 对应于最大并发数 4，您将强制执行该并发数（即，如果连接数超过 4，则断开连接）。现在，如果 S1 开始变慢（和以前一样），延迟将增加到 1 秒。并发限制为 4，延迟为 1 秒，您的费率现在仅为 4 EPS。所以你适应了缓慢而不杀死S1！

有关更多详细信息，请参阅Jon Moore 的题为“停止速率限制！容量管理做得对”的演讲，其中更详细。此外，您可能会发现 Netflix 博客文章Performance Under Load 关于自适应并发限制很有趣（GitHub 上的出色实现摘要）。