【问题标题】:Twitter Rate Limiting IP/OAuth ConcernsTwitter 速率限制 IP/OAuth 问题
【发布时间】:2012-08-24 16:15:06
【问题描述】:

我有一系列网络应用程序,它们使用Public Streaming API 收集与某个主题相关的所有术语。到目前为止,我一直在为每个流创建一个新帐户,在该帐户上设置一个新的 Twitter 应用程序,复制 OAuth 令牌,启动一个新的 EC2 实例,并设置流,这是一条非常非常艰巨的路线.

这使我可以拥有来自多个不同 IP 的流,在您创建应用程序时使用生成器工具可以轻松生成 OAuth,并且由于它们各自位于不同的帐户中,因此我不满足任何帐户限制。

我想知道我是否可以做些什么来加快这个过程,特别是在 EC2 实例方面。我可以使用不同的帐户在同一个实例上运行一堆流吗?

【问题讨论】:

  • 您是在问如何编写 EC2 实例生成脚本?
  • 可能是的。在链接页面的底部,有关于滥用 Publis Streaming API 的说法,它指的是一个帐户和一个 IP。因此,只要您使用不同的帐户,即使您从一个 IP 连接,您也应该处于绿色方面。但是,您确实应该联系 Twitter 以获取更多信息和确切的配额。

标签: twitter twitter4j twitter-streaming-api


【解决方案1】:

如果您在一台机器上运行多个消费者,您可能会被暂时禁止, 反复禁止可能最终使您被禁止更长时间。 至少,这种情况过去在我身上发生过几次。

我当时发现的是:

  • 相同的凭据,相同的 ip -> 阻止/禁止
  • 不同的凭据,相同的 ip -> 大部分都可以,但有时会被禁止
  • 不同的凭据,不同的 ip -> 好的

这是几年前的事了,所以我不确定是否仍然如此,但我希望 twitter 会收紧规则,而不是放宽规则。

(另外,我认为你侵犯了他们的 ToS)

【讨论】:

  • 有趣的结果...我发现不同的凭据,相同的 IP 总是每 15 分钟处理 15 条消息。我同意他们的条款...
  • 我的回答是几年前的事了,事情可能已经改变了:)
【解决方案2】:

您应该检查新的 Twitter API 版本 1.1。它是几天前发布的,对费率的计算方式进行了许多更改。

一个很大的变化是IP现在完全被忽略了。所以你不必再创建很多实例了(利润!)

来自 Twitter 开发者@episod:

与 API v1 不同,所有速率限制都是针对每个用户的每个应用 - IP 地址不涉及速率限制考虑。速率限制在应用程序之间完全划分。

【讨论】:

    猜你喜欢
    • 2012-01-20
    • 2011-11-16
    • 1970-01-01
    • 2014-08-05
    • 1970-01-01
    • 1970-01-01
    • 2022-08-19
    • 1970-01-01
    • 2015-04-21
    相关资源
    最近更新 更多