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