0

我们正在为我们的产品平台构建一个 Twitter 适配器，以使用 Search API 和 Streaming API 收集推文。我们开发了一个原型，它使用 Java Executor Service 和 Twitter4j 来收集推文并将它们提交到我们的推文队列。

以下是一些我们希望就以下方面提出建议的设计决策：

  1. 如何使适配器客户端具有可扩展性和容错性？
  2. 如何防止检索重复的推文？
  3. 如何在不达到速率限制的情况下最大化使用多个用户 ID 检索推文？
4

1 回答 1

1

一些答案，但请记住，自从我使用 twitter API 以来已经有一段时间了 -

为了使适配器具有可扩展性和容错性，您可以考虑以下技术 -

  1. 使用客户端的多个实例（即集群）——这实际上取决于它的作用，但您可以决定使用主动-主动或主动-被动集群模型
  2. 如果您选择集群 - 您是否有客户端连接到适配器？如果是这样，您将需要一个支持粘性会话的负载均衡器（因此在给定会话期间，客户端会寻址相同的适配器实例） - 检查 [this][1] 链接以获取一些信息。
  3. 我建议您对 twitts 使用缓存 - 如果我们将缓存视为键到值的映射，那么您的键可能是您用来从 Twitter API 获取信息的 URL（如果我记得，API 是某种 RESTful Web 服务）
    您应该在缓存上设置驱逐策略（即 - 数据被认为与您相关的时间） - 这可以帮助您提高性能，并减少对 twitter 的访问次数（我'我指的是你关于速率限制的问题的一部分）。
  4. 也许你应该看看你是否可以在用户之间共享信息——但这会涉及到一些逻辑。
    举个例子 - 如果用户 A 关注用户 B，而 B 关注 A，他们可能有更多常见的关注者或他们关注的用户，并且您可以共享数据。
  5. 如果你按照我之前的建议进行集群，你的缓存应该是分布式的。您可以为此使用EHCache
  6. 如果您将信息存储在数据库中 - 尝试通过构建线程本地基础缓存系统来最小化数据库访问（因此在一个线程中，如果您对同一实体执行两次获取相同的 ID，而无需写入，您将无法访问数据库两次...）

总之，这只是建议的冰山一角，您应该仔细了解您的需求、用例和流程，并了解如何优化它们中的每一个。

于 2012-06-26T07:46:02.050 回答