【发布时间】:2023-04-01 08:39:01
【问题描述】:
我发现了很多关于如何对 API 的用户进行速率限制的信息和脚本示例,但是我找不到任何示例来说明在施加这些限制时如何对您自己的 API 请求进行速率限制.
我一直使用诸如sleep 或usleep 命令之类的代码来限制我的脚本,但这感觉像是一种低效的做事方式,尤其是当 API 端点具有相当高的速率限制并敲击 API 直到你命中时限制也是低效的。
例如,Google 的 API 限制因您使用的 API 而异,并且可以增加/减少,在这种情况下,硬编码到代码中的固定速率限制看起来像是原始的猜测工作!
我是否遗漏了一些非常明显的东西?还是这不像我预期的那么普遍?
【问题讨论】:
-
你可以实现一个队列:将消息/动作放入队列,执行动作直到达到速率限制,解释限制消息并调整相同类型的队列消息,以便它们留在队列中直到你被允许再次处理消息。
-
好问题,没有简单的答案。 API:s 中的速率限制可以通过多种方式完成,并且在不同的平台上有所不同。一些 API:s 可以在标头中发送状态响应,例如 Twitter API 发送 [HTTP 429 “Too Many Requests” 响应代码][1],但除此之外,通常 API 客户端很难检测到何时超过限制.赞成这个问题,因为我期待在这个广泛的主题上阅读其他可能有智能解决方案/cmets的答案。 [1]:dev.twitter.com/rest/public/rate-limiting
-
谢谢两位,我一直按照你的建议 @NorbertvanNobelen 做过,但感觉有点原始。例如,谷歌对其某些 API 有每日限制和每秒限制,它更像是“每 X 秒/分钟”,这将是很好的管理,达到每日限制更多的是软件设计问题。我假设一个内存后端具有一个简单的接口,可以在需要时/在需要时处理暂停? (我想这可能很简单,我只是不想重新发明轮子!)。
-
+1。目前也在研究这个。想法是使用 Beanstalkd 等工作队列来解决秒/分钟限制。由于您的帖子被标记为
laravel,因此queue 文档可能会引起您的兴趣。 Redis with Celery 上的另一篇文章涉及分布式服务器,而不是单个服务器。像 twitter 这样的 spotify API 返回一个 429 响应。循环端点似乎很脏,排队应该很好,也许只有在达到限制时才暂停队列。