Instagram 实时 API POST 率

Question

我正在使用实时 API 中的标签订阅构建一个应用程序，并且有一个与容量规划相关的问题。我们可能有大量用户同时发布到订阅的主题标签，因此问题是 API 实际发布到我们的订阅处理端点的频率是多少？例如，如果 100 个用户在一两秒内发帖到 #testhashtag，我会收到 100 个 POST 还是 API 会将这些帖子一起批处理为一个更新？一个相关的问题:发送 POST 是否有最大速率(例如每秒一次或每十秒一次等)？

Answer 1

Instagram API 似乎缺乏有关发送的更新数量和速率限制的详细信息。来自 [API 文档][1]:

Limits Be nice. If you're sending too many requests too quickly, we'll send back a 503 error code (server unavailable).

You are limited to 5000 requests per hour per access_token or client_id overall. Practically, this means you should (when possible) authenticate users so that limits are well outside the reach of a given user.

换句话说，您需要检查 503 并相应地限制您的应用程序。我没有看到他们会阻止你多长时间的信息，但最好完全避免这种情况。我建议您通过在自己的代码上放置速率限制机制来管理此问题，例如通过具有速率控制的队列推送 API 请求。这也将为您带来重试的好处，这样您就不会丢失任何更新。

此外，由于 API 文档中的以下内容，诸如实时更新情况下的队列之类的机制更加相关:

You should build your system to accept multiple update objects per payload - though often there will be only one included. Also, you should acknowledge the POST within a 2 second timeout--if you need to do more processing of the received information, you can do so in an asynchronous task.

关于更新数量，API 可以向您发送 1 个或多个更新。问题是你绝对可以杀死你的 API 调用，因为我认为你不能批量调用特定的媒体项目，至少据我所知不能使用官方的 python 或 ruby​​ 客户端或 API 控制台。

这意味着，如果您收到 500 个更新，无论是作为对服务器的 1 个请求还是分成多个请求，都没关系，因为无论哪种方式，您都需要去获取这些项目。从我在实际应用程序中观察到的情况来看，这些似乎会计入我们的配额，但是配额本身似乎不规律地消耗资源。也就是说，有时我们根本没有看到任何调用被消耗，而其他时候可用调用的下降量远远超过我们实际调用的电话。我的建议是保守一点，将 5000 作为最佳猜测而不是绝对值。您可以通过解析它们发回的 header 之一来检查剩余的调用。

使用常识，不要犯傻，使用速率限制机制应该可以保证您的安全，并有利于处理由于中断(这种情况发生的次数比您想象的要多)、网络中断和意外造成的故障速率限制。您可以尝试巧妙地在池机制中使用不同的 API key ，但这可能违反 TOS，并且如果他们通过 IP 执行任何操作，您必须将其拆分到具有不同 IP 的不同计算机上。

我的最终建议是重组您的应用程序，使其不完全依赖订阅机制。它不太可靠，而且 API 非常昂贵。仅当您只需要在应用程序中执行某些操作而不需要回调到 Instgram、您的项目数量很少，或者您可以过滤掉大多数项目以避免在特定情况下回调到 Instagram 接受时，它才真正有用。业务规则匹配。

相反，您可以执行诸如查询标签或用户(例如:最近的媒体)之类的操作并以这种方式进行扩展。通常，这允许您通过 1 个请求获取 100 个项目，而不是通过 100 个请求获取 100 个项目。如果你真的想变得可爱，你至少可以异步合并订阅通知，并在将标签等重复特征合并到单个存储桶中时，将相似的通知合并到单个批量请求中。有点像映射/归约，但在小数据集上。当然，您可以不时对自己的数据进行实际的映射/归约，作为保持异步的另一种方式。再次强调，请注意不要破坏 Instagram，而只是使用 Map/Reduce 以对您的应用有用的方式批量处理您的调用。

希望有帮助。