速率限制简介

这是一个免费的博客文章，视频来自ShopifyDevs YouTube频道．在本系列的第一部分中，Shopify Plus的解决方案工程师Zameer Masjedee将通过在开发商店中使用私人应用程序的实际示例介绍一些解决速率限制的最佳实践。Zameer将首先定义什么是速率限制，以及为什么它对您很重要。然后，他将向您介绍Shopify使用的“漏桶”算法，以及它如何使商家和合作伙伴都受益。

入门:您将需要的OB欧宝娱乐APP工具

首先，从工具的角度来看，我们需要有一个开发存储．他们可以免费制作并注册使用Shopify合作伙伴帐户。您还需要在开发商店中安装一个私人应用程序，我们将介绍如何设置，以及您最喜欢的代码编辑器。在我的情况下，我将使用VS Code，但你可以使用任何你喜欢的。

如果您想准确地跟随我们正在做的事情，我将使用Ruby和Sinatra框架。但是您可以随意使用您喜欢的任何编程语言。

在系列结束时，我们将在Shopify上整合一个完整的端到端私人应用程序，该应用程序试图进行一些API调用，获得速率限制，然后处理它。

如果你对这类内容感兴趣，一定要订阅我们的ShopifyDevs YouTube频道，然后打开通知，这样你就知道我们什么时候放了新视频。

让我们开始吧。

你可能还喜欢:如何在一周内建立一个Shopify应用程序．

引入API速率限制

好吧，重要的先说。什么是API速率限制?

为此，我们将引入一些文档。

API速率限制本质上是Shopify确保平台稳定性的一种方式。我们有一个超级灵活的API，既支持REST (web标准)，也支持GraphQL(创新的新工具)。如果没有适当的速率限制，那么人们可以在任何时候有效地进行尽可能多的API调用。

“API速率限制本质上是Shopify确保平台稳定性的一种方式。”

从表面上看，这似乎很不错。当涉及到管理Shopify平台上的数据时，为什么你想要以任何方式受到限制?

这种思维过程的问题在于，它在规模上做得并不好。如果任何开发人员都有机会访问Shopify API，并且可以开始无限制地发出API请求，这对Shopify服务器来说是一个巨大的压力。最终，它可能导致停机。

宕机会影响我们的整个服务器，这意味着商家无法访问他们的商店，你的应用程序也无法工作。因此，API速率限制是我们控制任何给定应用程序在平台上可以发出的请求数量的一种方式。它确保您正在有效地进行API调用，并且当您进行API调用时，您将获得响应。

我们的服务器保持正常运行，响应时间很快，因为在整个平台上，我们能够保持稳定的请求水平。

探索不同类型的费率限制

让我们来看看一些细节。首先，重要的是要了解有不同类型的API速率限制。

最常见的速率限制类型可能是基于请求的限制，由REST管理API．在基于请求的限制中，速率限制与您发出的单个请求的数量相关联。

正如您在上面的API图表中看到的，我们有一列指定了标准Shopify计划的标准限制。对于Shopify Plus商家来说，这些数字实际上翻了一番。

在大多数情况下，我会尽量用标准的语言来表达。

REST管理API:基于请求的速率限制系统

使用Shopify REST管理API，您每秒会收到两个请求。这个限制很容易跟踪，并且可以让您了解在一分钟、一小时甚至一天的过程中可以提出多少个请求。

有了这种方法，你提出什么样的请求都无关紧要。每一个请求，不管它和前一个请求是一样的，不管你是在更新东西，删除东西，还是只是获取数据;它是每秒两个请求。

GraphQL管理API:一个基于积分的速率限制系统

GraphQL使用我们所说的计算查询成本，将请求限制提升到一个新的水平。这种方法仍然可以通过查询和突变读取和更新数据，但主要区别在于我们考虑了与每个请求相关的复杂性，因为有些事情(如更新数据)比简单地获取数据更耗费资源。

当涉及到任何GraphQL请求时，我们会考虑积分系统中的速率限制。在标准计划中，你每秒钟会得到50分。积分的工作方式非常简单。对于需要更新、创建或删除数据的任何变化，请求都要花费10分。另一方面，获取对象只需花费1分。

GraphQL有点意思。在这个特殊的视频中，我们不会深入讨论太多，但是可以在GraphQL中嵌套数据。

假设您想要一个订单，但是您也想要该订单中的每一个单行项目。这不会只损失一分。如果您的订单有10个项目，每个项目将花费1分，订单本身将花费1分，因此我们将为该请求查看11分。

这大致就是它的工作方式，当您查看GraphQL API时，自己计算起来非常容易。

在大多数情况下，GraphQL更加高效。因此，如果您现在还在犹豫该使用什么，出于这个原因，我们强烈推荐GraphQL(以及我们将在本系列后面提到的其他一些工具)。

Storefront API:一个基于时间的速率限制系统

API速率限制的最后一种方法是基于时间的限制店面API．这种方法与您发出的请求数量无关，而与这些请求之间的时间长短有关。

这用于我们的headless实现，因此我们不会在本文中花太多时间在它上面，但是理解它们的区别是值得的。

漏桶算法

当谈到理解Shopify的速率限制时，第二个主要部分是理解漏桶算法。

考虑漏桶算法的最好方法是想象一个桶，里面装着预定数量的弹珠。一秒一个弹珠漏出来，这意味着你可以以同样的速度增加另一个弹珠。如果你的桶太满了，你就不能再加弹珠了。你的桶能装多少弹珠取决于几件事。

使用REST管理API的标准计划是每个应用程序、每个商店有40个请求。

这是为了明确，如果你有一个公共应用，它安装在两个商店，这两个安装之间没有关系或依赖。它们每一个都有自己独立的利率上限。在REST管理API的情况下，它们被分配为40个请求的桶大小-因此您有空间从您的私有应用程序或公共应用程序发出40个请求。

“如果你有一个公共应用程序，它安装在两个商店，这两个安装之间没有关系或依赖关系。它们每一个都有自己独立的利率上限。"

假设我们想创造一种新产品。太棒了。正如我们前面提到的，REST中的一切都很简单。每个请求都被视为一个请求，以达到您的速率限制。

所以我们创造了一个产品，然后把一个弹珠扔进桶里。当我们第二次想要做某事时，比如更新或删除数据，我们将把另一个弹珠扔进桶中。

你可以看到，随着时间的推移，这个桶会慢慢变满。只有当你有足够的空间把另一个弹珠扔进桶里时，你才能提出请求。如果它已经满了，你试着扔一个弹球进去，Shopify就会回应一个429错误:“请求太多了。”“你已经达到了你的利率上限。”“我们无法处理您的请求。”你得等一等。

这就是漏洞所在。

你确实有40个请求。然而，与此同时，它也在不断消耗之前的请求。

你可能还喜欢:开始使用GrapOB欧宝娱乐APPhQL．

这是什么意思?

这意味着每秒钟泄漏率为每秒两个，您的存储桶就会多出两个弹珠或两个请求的空间，假设它里面有任何东西。如果它完全是空的，您在过去一小时内没有发出请求，那么桶的大小仍然是40。你不会得到任何额外的空间。

你不能泄露任何不存在的东西。

如果你提出请求，假设你在一秒钟内提出了10个请求，那么你就填满了桶里40个弹珠中的10个。一秒钟后，其中两个就会消失。现在你的桶里有8个弹珠，还可以再放32个，或者再放32个请求。

为什么是漏桶算法?

我们实现这种非常直接的方法的原因是，如果我们只是给出每秒两个呼叫的标准速率限制，那么您将无法灵活地处理突发请求。

假设您的应用程序是这样工作的:收到一个订单，每次更新该订单中包含的所有产品，并增加存储在其标记中的值(可能是为了跟踪您总共销售了多少产品)。

每个订单都有X次产品更新。

您可以很快看到，进来的订单越多，您必须提出的请求也就越多。

使用漏桶方法，因为您的桶大小为40，如果有20个产品的订单，您可以同时对这些产品中的每个产品发出20个不同的请求。

“同时发出突发或一组请求的能力给你和你的应用带来了更多的灵活性。”

即使泄漏率是每秒两次调用，你的桶里还是有空间的因为你有20个弹珠进去，一秒钟后，两个弹珠出来，就只剩下18个了。你可以慢慢地看到，一次发出突发或一组请求的能力如何给你和你的应用带来了更多的灵活性。

这就是为什么我们选择用这种方式来实现它。

当涉及到GraphQL时，情况非常相似。你也会得到一个桶;只不过桶的大小不同而已。

在这种情况下，桶被赋予1000个成本点。泄漏率是每秒50个。同样，突变和对象的代价各不相同。

我们有更多的定义在文档中变化和查询的成本。

这些信息将帮助您了解在一段时间内使用GraphQL可以发出多少或多少个请求。

我们对利率限制的介绍到此结束。我们有不同的方法，不同类型的请求，以及为什么漏桶算法存在于平台稳定性。

漏桶算法:需要考虑额外的数据

最后我想分享一些有趣的数据，因为我喜欢数据。这是我们的API体积。这只是我从过去30天左右的数据集中任意选取的一天。

在一天之内，你可以看到我们最流行的4个REST端点，当涉及到API请求时，我们谈论了多少量。

产品每天有222个API调用，InventoryLevels看到1.58亿，订单有1.37亿，元字段有1.06亿。

有大量的流量通过Shopify的服务器。我们实施费率限制是因为这是负责任的事情，因为这意味着我们可以为我们的商家和合作伙伴提供最高水平的稳定性和正常运行时间。

我们感谢开发人员负责地在这些速率限制内构建应用程序。在本系列的下一篇文章中，我们将更多地讨论速率限制最佳实践。