开发可扩展的Twitter数据适配器

Question

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

以下是我们要求提出建议的一些设计决策：

1. 如何使适配器客户端可扩展且容错？
2. 如何阻止检索重复的推文？
3. 如何在不达到速率限制的情况下，使用多个用户ID最大限度地检索推文？

Answer 1

一些答案​​，但是记住它已经有一段时间了，因为我使用了twitter API -

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

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

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