我有时会收到来自 API 的节流违规错误
{'error_id': 502, 'error_message': 'Violation of backoff parameter', 'error_name': 'throttle_violation'}
尽管遵守了从 API 收到的退避命令。我反复检查了我的日志,并验证了从收到退避参数(在我的情况下始终为 10 秒)到发送下一个请求之间是否经过了所需的时间。我还设置了每秒 25 个请求的限制,以便在请求顺利进行时使用。
过去这种情况经常发生,但自从我开始增加 0.5 秒以防时间四舍五入为整数秒后,情况有所好转。这个 0.5 秒的余量似乎有所帮助,但现在我又看到了这样的“违规”。我希望与 API 保持友好关系,并始终尊重她的界限。
我做错了什么吗?问题的根源可能是什么?我能做些什么来避免它?如果我无法避免它,我有什么选择?
我已经检查了潜在的嫌疑人,如相关文章所建议的那样:
- 速率限制低于每秒 30 个请求,此外,我检查了日志以确认请求时间
- 没有其他进程可能从同一 IP 发出 API 请求 []
- 所有请求均按顺序发出,没有请求并行发出 []
3
最佳答案
1
简短的回答是:无论你做什么,甚至可能只发出一个请求,你都会遇到这些错误。你的代码只需要处理收到的错误并执行恢复操作。
如果没有您的代码,我们就无法判断您是否做错了什么,但您遇到Violation of backoff parameter
错误并不一定意味着您实际上违反了backoff
SE 的 API 发送给您的规定。
SE API 可以发送该错误,而无需您实际违反任何规则,backoff
也无需 SE API 事先向您发出任何希望您减少请求的迹象。您是否会收到该错误,或者 SE 会以其他方式限制 SE API 的使用者,取决于您对 SE API 施加的负载以及 SE API从所有人的请求中承受的总体负载。
基本上,如果您收到任何指示节流的错误,则需要等待一段时间。如果 SE API 没有为您提供时间,则需要选择一个等待时间。在该时间到期后,尝试单个请求。如果您没有收到错误,那么通常可以恢复正常运行。
3
-
1是的,这正是我在开发使用 SE API 的机器人时独立发现的。尽管根据所有现有证据,你遵循了所有记录的规则,但被告知你做错了(违反了退避参数),这非常令人沮丧。我找不到任何记录。我最终做了同样的事情,等待一段任意的、预定义的时间长度(在我的情况下是 20 秒),然后再试一次。API 请求几乎总是在下一次成功。
– -
2还值得注意的是,希望通过在发生此类错误时返回建议的退避值来修复此问题,这样您就不必仅仅猜测合适的时间是多少(因此,如果猜测的时间不够长,则可能会再次出现退避错误)。不幸的是,9 年后,这项基本功能仍未实现。
– -
我发现,对于我的大部分使用情况来说,增加两秒钟的退避时间就足够了
–
|
–
/posts/{ids}
请求单个帖子)耗时 490 毫秒,而向/questions/{id}/flag/options
端点发出的针对同一问题的后续请求耗时 116 毫秒。因此,如果您一次只有一个请求,则接近每秒 25 个请求的可能性极小。我应该指出,您可以同时发出多个请求。我有一个用户脚本,可以执行此操作,直至达到可配置的数量。我积极使用了 5 到 10 个请求。–
/users/{ids}/reputation-history?page=1
,page=2
等等。我没有对它们进行计时,但它们似乎很快。可能是 SE API 方面采用了一些智能抢占式缓存。–
|