Instagram实时API发布率

Question

我正在使用实时API中的标记订阅构建一个应用程序，并有一个与容量规划有关的问题。我们可能会有大量的用户同时向订阅的标签发帖，所以问题是API会多长时间向订阅处理endpoint发帖？例如，如果在一两秒钟内有100个用户发帖到#TestHashtag，我会收到100个帖子还是API将这些帖子作为一个更新进行批处理？一个相关的问题：是否有发送邮件的最大速率（例如，每秒一个或每十秒一个，等等）？

Answer 1

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

限制很好。如果您发送太多的请求太快，我们将发回一个503错误代码（服务器不可用）。

每个access_token或client_id每小时的请求总数限制为5000个。实际上，这意味着您应该（在可能的情况下）对用户进行身份验证，以便限制远远超出给定用户的范围。

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

此外，在实时更新的情况下，队列之类的机制也更加相关，因为API文档中有以下内容：

您应该将系统构建为每个有效负载接受多个更新对象--尽管通常只包含一个更新对象。此外，您应该在2秒超时内确认POST--如果需要对接收到的信息进行更多处理，可以在异步任务中这样做。

关于更新的数量，API可以向您发送1个更新或多个更新。这样做的问题是，您可以完全取消API调用，因为我认为您不能批量调用特定的媒体项，至少在我所看到的情况下，不能使用官方的python或ruby客户机或API控制台。

这意味着，如果您接收到500个更新，无论是作为对服务器的1个请求还是分成许多请求，这都无关紧要，因为无论哪种方式，您都需要去取这些项。从我在一个实际应用程序中观察到的情况来看，这些似乎与我们的配额有关，但是配额本身似乎不正常地消耗资源。也就是说，有时我们看到根本没有呼叫被消耗，而其他时候可用呼叫的下降远远超过我们实际拨打的。我的建议是保守一点，把5000作为一个最好的猜测，而不是绝对的。您可以通过解析它们发回的其中一个头来检查其余的调用。

使用常识，不要愚蠢，使用速率限制机制应该可以保证您的安全，并且可以处理由于中断（这种情况发生得比您想象的多）、网络打嗝和意外速率限制造成的故障。您可以尝试在池机制中使用不同的API密钥，但这可能违反了TOS，如果他们通过IP做任何事情，您必须将其拆分到具有不同IP的不同机器上。

我最后的建议是重新构造您的应用程序，使其不完全依赖订阅机制。它不太可靠，而且API非常昂贵。只有当您只需要在应用程序中做一些不需要回调到Instgram的事情，您的项目数量很少，或者您可以过滤掉大多数项目，以避免在匹配特定业务规则时回调到Instagram accept时，它才真正有用。

相反，您可以查询标记或用户（例如：最近的媒体），并以这种方式向外扩展。通常，这允许您用1个请求抓取100个项目，而不是用100个请求抓取100个项目。如果您真的想变得可爱，您至少可以异步合并订阅通知，并在将重复的特征（如tag）组合到单个bucket中时将相似的通知组合到单个批处理请求中。有点像map/reduce，但在一个小数据集上。当然，您可以不时地对自己的数据进行实际的映射/缩减，作为保持异步的另一种方式。同样，要注意不要攻击instagram，而是使用map/reduce以一种对你的应用程序有用的方式批量处理你的调用。

希望能有所帮助。