如何以编程方式处理服务器吞吐量配额？

Question

我有一个程序可以对Google Search Analytics 服务器进行许多查询。我的程序一个接一个地执行查询，所以每一瞬间，只有一个查询在处理中。

Google 已建议每 100 秒最多 2000 个查询的吞吐量限制，因此为了将我的系统配置为更高效，我可能有两个想法：

1. 知道每 100 秒 2000 个查询是每 0.05 秒一个查询，我通过休眠进程来分隔查询，但前提是任何查询花费的时间少于 0.05 秒，因此进程将休眠的时间这种情况是完成 0.05 秒间隔的剩余时间。如果查询需要 0.05 秒或更长时间，我无需等待即可触发以下操作。

2. 第二个想法更容易实现，但我认为效率会降低：我将触发查询并记录进程开始的时间，因此如果我在 100 秒之前达到 2000 个查询，我将等待剩余的睡眠时间。

到目前为止，我不知道如何衡量哪个是最好的。

您对这两个选项有何看法？它们中的任何一个都更好，为什么？我还没有想到任何其他选项？ （特别是如果它比我的好）

Answer 1

实际上你需要考虑的是它每 100 秒有 2000 个请求。但是您可以在 10 秒内完成所有 2000 个请求，并且仍然处于配额的有利位置。

我很好奇你为什么担心它。如果您遇到以下错误之一

• 403 userRateLimitExceeded
• 403 rateLimitExceeded
• 429 RESOURCE_EXHAUSTED

Google 只是建议您实现Exponential backoff，这包括让您的请求让错误休眠一段时间并重试。 （最多做八次）。谷歌不会因为你出现这些错误而惩罚你，他们只是要求你稍等片刻再试一次。

如果你想发疯，你可以像我在我的 C# 应用程序中所做的那样做一些事情，我创建了一个请求队列，我用它来跟踪自创建最后 100 个请求以来已经过去了多少时间。我叫它Google APIs Flood Buster。

基本上，我有一个队列，在我提出新请求之前，我会在其中记录每个请求，我会检查自开始以来它已经过去了多长时间。是的，这需要稍微移动队列中的项目。如果已经超过 90 秒，那么我会睡觉（100 次之后），这大大减少了我的错误。它并不完美，但那是因为谷歌在跟踪您的配额方面并不完美。它们通常会偏离一点。