我们计划为基于休息的框架实施速率限制器。但我有点困惑哪一个实现，哪一个在并发和速率限制之间更重要。 我发现在大多数地方，例如apache camel人们已经实现了速率限制而不是并发。 但对我来说，速率限制实际上几乎没有任何意义，相反，并发性是我们对面临多个并发请求的服务总是需要的？ 请让我知道你对此的想法。
答案 0 :(得分：0)
您当然希望尽可能多地默认提供并发请求。但是，高于某些请求率，您的服务性能可能会大幅降低。当发生这种情况时，每个客户端都会受到影响而您不再提供更多请求，而是越来越少，直到您的服务对任何人都无法使用。速率限制允许您不要让新请求以某种速率进入系统，因此不会降低性能。你看似一些客户，但至少有一些客户服务，你仍然可以操作你的系统，而不是从过度交换或垃圾收集，当你甚至无法连接它时，有效地将整个服务器带到它上面。
特定客户端的速率限制（例如基于IP）可以减轻“坏”客户端的影响，这些客户端每个时间单元发出的请求过多或者尝试帮助您。
请记住，通过将您的服务置于某种反向代理（如nginx）之后，可以调整请求率。 it can让请求等待并且一段时间没有进入你的系统（并且nginx可以保持很多这些等待而不会降低性能），它可以完全丢弃它们，它可以限制基于IP的请求等。
答案 1 :(得分：0)
如果您正在销售API并希望维持一定的价格模型，则价格限制可能最有用。
对于弹性用例（例如，保护API避免过载），并发限制是更有意义的，因为它对于系统的更改更灵活，并且提供了一种实现背压的简单方法。
为了说明，这是一个例子：
服务器S1可以处理10 EPS（每秒事件）的速率。为了安全起见，您决定将呼叫限制为8个EPS。现在S1开始遇到一些问题（例如，开发人员使代码的性能降低，磁盘问题等），并且只能处理5个EPS。在相同的速率限制下，您将继续锤击S1，并且最终将死亡。
您可以使用Little's Law计算等效的并发限制。如果您的平均延迟时间是0.5秒，则8个EPS对应于最大并发4，您可以强制执行（即，如果连接超过4个，则丢弃连接）。现在，如果S1开始变慢（和以前一样），则延迟将增加到1s。并发限制为4，延迟为1s，您的费率现在仅为4 EPS。这样您就适应了缓慢性，而不会杀死S1！
有关更多详细信息，这是乔恩·摩尔（Jon Moore）的题为“ Stop Rate Limiting! Capacity Management Done Right”的演讲，其中有更多细节。另外，您可能会发现有关自适应并发限制的Netflix博客文章Performance Under Load （有趣的实施摘要on GitHub）。