Question

我有时会收到来自 API 的节流违规错误

 {'error_id': 502, 'error_message': 'Violation of backoff parameter', 'error_name': 'throttle_violation'}

尽管遵守了从 API 收到的退避命令。我反复检查了我的日志，并验证了从收到退避参数（在我的情况下始终为 10 秒）到发送下一个请求之间是否经过了所需的时间。我还设置了每秒 25 个请求的限制，以便在请求顺利进行时使用。

过去这种情况经常发生，但自从我开始增加 0.5 秒以防时间四舍五入为整数秒后，情况有所好转。这个 0.5 秒的余量似乎有所帮助，但现在我又看到了这样的“违规”。我希望与 API 保持友好关系，并始终尊重她的界限。

我做错了什么吗？问题的根源可能是什么？我能做些什么来避免它？如果我无法避免它，我有什么选择？

我已经检查了潜在的嫌疑人，如相关文章所建议的那样：

每秒25 个请求太高了。您说没有请求同时进行。为了实现每秒 25 个请求，每个请求需要花费不到 40 毫秒的时间。除非您遇到错误，否则这根本不可能发生。嗯…我想也许吧，如果请求几乎微不足道。在正常运行中，如果请求组合半正常，如果您一次只有一个请求在进行，并且没有遇到错误，那么您将无法接近每秒 25 个请求。 — 
简要查看我使用/工作的用户脚本 FIRE 发出的几个请求，向端点发出请求（/posts/{ids}请求单个帖子）耗时 490 毫秒，而向/questions/{id}/flag/options端点发出的针对同一问题的后续请求耗时 116 毫秒。因此，如果您一次只有一个请求，则接近每秒 25 个请求的可能性极小。我应该指出，您可以同时发出多个请求。我有一个用户脚本，可以执行此操作，直至达到可配置的数量。我积极使用了 5 到 10 个请求。 — 
@Makyen “每秒 25 个请求太高了……每个请求需要花费不到 40 毫秒的时间。” – 实际上，我不知道我是否曾经达到过这个速率，这只是代码中设置的一个约束。“请求单个帖子需要 490 毫秒，而 [相关请求] 需要 116 毫秒” – 我有一系列请求/users/{ids}/reputation-history?page=1，page=2等等。我没有对它们进行计时，但它们似乎很快。可能是 SE API 方面采用了一些智能抢占式缓存。 —

Accepted Answer

简短的回答是：无论你做什么，甚至可能只发出一个请求，你都会遇到这些错误。你的代码只需要处理收到的错误并执行恢复操作。

如果没有您的代码，我们就无法判断您是否做错了什么，但您遇到Violation of backoff parameter错误并不一定意味着您实际上违反了backoffSE 的 API 发送给您的规定。

SE API 可以发送该错误，而无需您实际违反任何规则，backoff也无需 SE API 事先向您发出任何希望您减少请求的迹象。您是否会收到该错误，或者 SE 会以其他方式限制 SE API 的使用者，取决于您对 SE API 施加的负载以及 SE API从所有人的请求中承受的总体负载。

基本上，如果您收到任何指示节流的错误，则需要等待一段时间。如果 SE API 没有为您提供时间，则需要选择一个等待时间。在该时间到期后，尝试单个请求。如果您没有收到错误，那么通常可以恢复正常运行。

是的，这正是我在开发使用 SE API 的机器人时独立发现的。尽管根据所有现有证据，你遵循了所有记录的规则，但被告知你做错了（违反了退避参数），这非常令人沮丧。我找不到任何记录。我最终做了同样的事情，等待一段任意的、预定义的时间长度（在我的情况下是 20 秒），然后再试一次。API 请求几乎总是在下一次成功。 — 
还值得注意的是，希望通过在发生此类错误时返回建议的退避值来修复此问题，这样您就不必仅仅猜测合适的时间是多少（因此，如果猜测的时间不够长，则可能会再次出现退避错误）。不幸的是，9 年后，这项基本功能仍未实现。 — 
我发现，对于我的大部分使用情况来说，增加两秒钟的退避时间就足够了 —

我遵守了退避命令，但仍然收到“违反退避参数” – Meta

最佳答案
1