我正在使用实时API中的标记订阅构建应用程序，并且有一个与容量规划相关的问题。我们可能会有大量用户同时发布到订阅的主题标签，因此问题是API实际发送到我们的订阅处理终端的频率是多少？例如，如果100个用户在一两秒钟内发布到#testhashtag，我会收到100个POST，还是将这些API批量作为一个更新？一个相关的问题：是否有最大速率可以发送POST（例如，每秒一个或每十秒一个等）？
答案 0 :(得分：6)
Instagram API似乎缺乏有关发送了多少更新以及速率限制的详细信息。来自[API docs] [1]：
限制 对人好点。如果您过快地发送过多请求，我们会发回 503错误代码（服务器不可用）。
每个access_token或client_id整体限制为每小时5000个请求。实际上，这意味着您应该（在可能的情况下）对用户进行身份验证，以便限制远远超出给定用户的范围。
换句话说，您需要检查503并相应地限制您的应用程序。没有任何信息我已经看到他们可能阻止你多久，但最好完全避免这种情况。我建议您通过在自己的代码上设置速率限制机制来管理这一点，例如通过具有速率控制的队列推送您的API请求。这也会让您重新受到限制，这样您就不会失去任何更新。
此外，由于API文档中的以下内容，在实时更新的情况下，诸如队列之类的机制也是相关的：
您应该构建系统以接受每个有效负载的多个更新对象 - 尽管通常只包含一个。此外，您应该在2秒超时内确认POST - 如果您需要对接收到的信息进行更多处理，则可以在异步任务中执行此操作。
关于更新次数，API可以向您发送1次更新或更新。这个问题是你绝对可以谋杀你的API调用，因为我不认为你可以批量调用特定的媒体项目，至少不会使用官方的python或ruby客户端或API控制台，就我所见。
这意味着，如果您收到500个更新作为1个请求到您的服务器或分成许多，它就不重要，因为无论哪种方式，您都需要去获取这些项目。根据我在实际应用中观察到的情况，这些似乎与我们的配额相比，但配额本身似乎不规律地消耗资源。也就是说，有时我们看到根本没有消耗掉任何呼叫，有时候可用呼叫的丢失远远超过我们实际的消耗。我的建议是保守，把5000作为最佳猜测，而不是绝对。您可以通过解析他们发回的一个标头来检查剩余的呼叫。
使用常识，不要愚蠢，并且使用速率限制机制应该保证您的安全，并且有利于处理由于中断导致的故障（这种情况比您想象的要多），网络打嗝，和意外的速率限制。您可能会尝试使用不同的API键并在池化机制中使用不同的API密钥，但这可能违反了TOS，如果他们通过IP执行任何操作，您必须将其拆分为具有不同IP的不同计算机。
我的最终建议是重新构建您的应用程序，而不是完全依赖订阅机制。它不太可靠且非常昂贵的API。它只是真正有用的，如果你只是需要在你的应用程序中做一些不需要回调到Instgram的东西，你的项目数量很少，或者你可以过滤掉大部分项目以避免回电到Instagram时接受特定业务规则的匹配。
相反，您可以执行查询标记或用户（例如：最近的媒体）等内容并以此方式进行扩展。通常，这允许您使用1个请求获取100个项目，而不是100个具有100个请求的项目。如果你真的想要可爱，你至少可以异步合并订阅通知，并在将重复的特征（如标记）组合到一个存储桶中时将相似的订阅通知合并到一个批处理请求中。有点像map / reduce，但是在一个小数据集上。你当然可以在你自己的数据上不时地做一个实际的map / reduce，作为保持异步的另一种方式。同样，小心不要鞭打Instagram，而只是使用map / reduce以对您的应用程序有用的方式批量拨出您的电话。
希望有所帮助。