使复合物变得简单

现代软件工程提供了许多现成的工具，使开发更快，更容易。棒极了！但这并不意味着我们只能忽略事物在幕后的实际工作方式。

在这个简单明了的文本中，我将解释一些有关费率限制器的信息，以及为什么值得知道它们如何打勾。

为什么？

当涉及API时，管理请求，寄回响应并处理复杂的业务规则都占用资源。当这些资源用完时，通常会转化为需要更多的基础架构并淘汰额外的现金。如果您为客户提供服务，这是API运作方式的基本思想。但是，无论您的API功能如何，它可以处理的请求数量总有一个门槛 - 无论是数千万还是数百万。最终，在某个突破点，特定时间范围内的请求量变得不堪重负。

只是某些API及其速率限制器的一个例子：

Twitter API：将速率限制应用于Twitter API的不同端点和功能。例如，标准搜索API具有速率限制，例如用户认证请求的每15分钟窗口的180个请求。


github api：对API请求执行速率限制，这取决于请求是否已验证。对于未经验证的请求，与经过认证的请求相比，费率限制可能更低。

Stripe API：对API的付款处理和相关功能施加了费率限制。特定速率限制可能会根据特定的API端点而有所不同。

Twilio API：在发送SMS，拨打电话和其他通信服务时设定了速率限制。速率限制可以特定于使用的通信类型和使用的Twilio服务。

请记住这一点：利率限制器在服务级别而不是网络级别运行。因此，您不会监督数据包和IP地址；相反，您正在处理端点和服务请求。

如何？

让我们从澄清您要从确切地保护系统中的什么开始。
一些例子：

1. 用户每秒不超过2个文章。
2. 您每天可以从同一IP地址创建10个帐户
3. 您可以从同一设备中要求每周不超过5次奖励 由于缺乏创造力，我从Alex Xu Book，System Design采访
中取了这些例子

现在您有自己的要求，请回答一个重要的问题，请在下面发表评论，然后再阅读：
您应该将价格限制器放在哪里？

客户对客户的评价限制器

好吧，让我们挖掘我们拥有的机会。

毫无疑问，这是一个功能性的选择。但是，有几个缺点。即使它阻止您的应用程序处理不希望的请求，该解决方案在客户端很容易受到伤害。他们可以通过删除模块来轻松绕过它，允许没有速率限制的请求。

API上的速率限制器

这种方法也有效。它使您可以阻止客户更改应用程序以绕过速率限制器。但是，权衡是您将管理API本身内的速率限制器处理，旨在使其免受不希望的请求的影响。这使API无法执行不必要的说明，但仍然不是理想的。

费率限制器作为代理

这可能是解决此问题的最精制解决方案。通过实施速率限制器来管理这些请求，您可以有效地筛选并从服务API中淘汰所有不希望的处理。当然，有一些缺点，例如引入一个用于管理的其他软件组件以及网络超载的潜力。但是，考虑到这些好处，这是一个合理的权衡。

算法

现在，我们已经掌握了速率限制器概念，让我们深入研究如何自己建造一个概念。值得注意的是，众多公司为利率限制提供了预制的解决方案，并且还有一些提供类似功能的开源项目。但是，本文档的目的是探索其背后的内部工作原理。

令牌桶列表

在各种限制算法中，由于其简单性和有效性，我们将重点关注令牌列表。我们会深入研究其机制，因为它提供了一种直接而有效的方法。

从本质上讲，该算法涉及一个“ refiller”，该算法会逐渐增加令牌，​​直到达到预定义的最大值为止。超出此最大值的任何其他令牌在溢出时基本上丢失了。

此过程发生在速率限制器应用程序的生命周期内，与请求生命周期不同。收到请求后，消耗了令牌。如果没有令牌，请求将以“ 429个请求太多”状态响应，从而有效地拒绝该请求。在这种情况下，由于缺乏可用的令牌，请求被拒绝。

给定所述情况，只有2个令牌可用和3个传入请求，使用可用的令牌可以通过前两个请求。但是，第三个请求被拒绝并符合“太多请求” HTTP响应，从而被解雇。

代码

随时可以在我的technical blog和repositoryð

上探索令牌桶代码

如果您发现内容有价值，请考虑订阅我的Newsletterð

记住，此内容是自由提供的，并且将永远保持下去。如果您发现它有帮助，请考虑支持我，buy me a coffee

我渴望在评论部分中听到您的想法。

希望我变得复杂，简单。