【问题标题】：Facebook Application Rate Limit #4 - June 2018 BugFacebook 应用程序速率限制 #4 - 2018 年 6 月错误
【发布时间】：2018-06-20 11:24:28
【问题描述】：

Facebook 似乎遇到了速率限制方面的错误。在撰写本文时，该错误已经开放了好几天。我相信每个人都知道这会严重影响这些开发人员的客户群。

请求限制似乎是零星的，并且与文档不相符。实际速率限制似乎已急剧增加，与“正常”相比，只允许一定百分比的请求似乎有几个人受到了影响：

https://developers.facebook.com/support/bugs/169774397034403/

是否有人有任何解决方法、建议或见解来缓解这个问题？

提交的原始错误报告：

我们的应用程序遇到了“GraphAPIError: (#4) 过去的应用程序请求限制已达到”错误打开和关闭几天。我们的应用程序监控我们的几个用户帐户并为每个 FB 页面提取数据，过去几年一直如此进行了许多 API 调用以收集这些帐户的指标通常会在每天不到两个小时的时间内发生。 5 月 25 日，我们能够进行我们通常进行的 API 调用的 1% 由于应用程序速率限制，超过 24 小时。 5月26日，我们收到了我们通常在 24 小时内进行的 3% 的 API 调用到相同的应用程序速率限制。然后在 27 日到 29 日，它去了恢复正常，在不到 2 小时的时间里，我们能够完成 100% 的我们通常进行的 API 调用，没有错误。然后在 30 日，我们能够进行 33% 的正常 API 调用，到目前为止，第 31 次我们已经能够进行 1% 的正常 API 调用。没有什么我们已经改变了，我们没有理由只能够进行 1% 的 API 调用通常需要几天时间而不是其他日子，特别是因为我们的应用程序一直在做同样的事情几年前的确切事情。它感谢任何帮助。

【问题讨论】：

可能重复：stackoverflow.com/questions/50719641/…

标签： facebook facebook-graph-api rate-limiting

【解决方案1】：

因此，我们也遇到了速率限制问题。

我们的解决方案有两个。

第一步，对于一直遇到速率限制的客户（原因是他们每天只有一个活跃用户但管理着数百个页面），我们正在向应用添加用户（员工用户）。由于外出应用程序用于安排帖子，因此我们已安排每个“新”用户每天发布帖子。这增加了应用程序的每日活跃用户数量，从而提高了 api 的吞吐量。

长期解决方案是我们正在构建一个新服务来管理所有 api 调用。它将分析应用程序的吞吐量，根据需要限制 api 调用，并提供有关正在发出的调用以及来自哪个客户/应用程序的报告洞察，以便我们更好地优化发出的调用。

只需安装一个 SDK 就可以轻松搞定，但看起来这已经不再适用了。

【讨论】：

+1 关于创建专门的服务来处理 API 调用，这似乎成为了规避此类问题的必要条件。
@RiaanvanZyl 谢谢。我知道这是一个模棱两可的声明，所以我想我会更多地分享我是如何处理它的。我们将利用使用 AWS 的事件总线架构来抽象来自核心平台的所有调用。然后使用专用的微服务来分析和处理 API 调用。这些家伙有一套惊人的工具来完成这样的事情。 https://www.leoplatform.io

【解决方案2】：

我的应用程序会定期查询我们自己和竞争对手的几个页面的帖子。（媒体网站 facebook 页面链接到新闻文章。我们喜欢将帖子和表现与竞争对手进行比较。）

我为减少此问题所做的工作是将应用令牌用于竞争对手的帖子，但将特定于页面的令牌用于我们自己的页面帖子。这显着减少了对应用令牌的调用量，从而导致速率限制的启动频率大大降低。

【讨论】：

欲了解更多信息：developers.facebook.com/blog/post/2016/06/16/…

【解决方案3】：

我的解决方案：

因为我们只访问page/{page-id} 端点，所以我们计算了每个请求的新帖子数，并延迟了对同一资源的下一个请求。

因此，如果我们查询 API 并在 100 个项目中收到 1 个新项目，我们将显着增加再次调用同一资源（页面 ID）之前的等待时间。

当我们收到更接近“完整”的响应（即 90/10）时，我们会再次稍微增加时间。这样我们就不会在请求“陈旧”数据时浪费请求。

我们还确保只调用我们的“优先页面”，从而减少竞争请求的项目总数

注意事项：

Facebook Dashboard 上的 Rate-Limit 小部件未反映 API 的响应：

即使仪表板没有反映限制，我们确实收到通知：

{Application Name} 已达到每小时速率限制的 100%。所有 API 调用您的应用程序将失败，直到您的应用程序低于限制限制。

根据文档，代码 4 特定于应用令牌：

https://developers.facebook.com/docs/graph-api/advanced/rate-limiting

检查标头发现原因是“total_time”（请求的间隔正好是 10 秒，直到我们收到 403 响应）：

【讨论】：

我试过了，但它最终又发生了。我的应用程序经常每 10 分钟打一个电话。我将差距增加到 15 并且它起作用了。几天后它再次开始失败，所以我将它增加到 30，然后是 45，然后是一个小时。它只是暂时起作用
@Zerquix18 的总时间是否也受到限制？

【解决方案4】：

我们的应用程序也有同样的问题。这是我能够收集到的一些（完全）经验证据。我们的应用程序从某些公共页面获取数据（帖子和 cmets）。我们使用 APP 令牌（不是用户令牌）。

当我们尝试获取 2 级 cmets，即其他 cmets 下面的 cmets 时，似乎总是会发生速率限制错误 #4。当我们试图从评论中获得反应时偶尔会发生（甚至是 1 级 cmets）。

这完全是经验证据。但如果其他人可以复制这一发现，那就太好了。

【讨论】：

【解决方案5】：

这对我有用。如果我将脚本限制为每 3650 秒 200 个 API 调用，它将运行完成。这些数字似乎接近我能做的最好的数字。如果我逐渐增加 API 调用次数或逐渐减少秒数，脚本开始间歇性地失败。如果我更改太多，脚本会一直失败。

这可能意味着某些脚本无法在一天内完成。幸运的是，我的在几个小时内完成。

【讨论】：