内容聚合服务策略答案

【问题标题】：Strategy for content aggregator service内容聚合服务策略
【发布时间】：2011-12-15 22:01:32
【问题描述】：

我已经为使用 php/Mysql 的客户端构建了 RSS、twitter 和其他内容聚合器。它通常涉及一项 cron 作业、一些提要解析和将数据插入数据库以进行存储和稍后重新发布、删除或存档等。没有什么突破性的。

但现在我的任务是为公众构建一个聚合器服务。我想这将需要快速扩展，因为每个有权访问该服务的人都可以添加数十个（如果不是数百个）源提要。在几个月内，我们可能会定期解析 1000 个提要，一年内可能会解析 100,000 个提要，如果运气好的话，可能会更多。

我想最终的模型类似于谷歌阅读器所做的。

那么，有什么好的策略呢？多个重叠的 crons、持续运行和阅读提要并连接到 API 以提取内容？我应该计划运行多个 Elastic Cloud 实例还是随着需求的增长而运行？

【问题讨论】：

解释“队列”？我不熟悉。
它是一种软件。例如，RabbitMQ 是队列管理器之一
对 RabbitMQ 很感兴趣。所以看起来我在专用服务器上设置了它，让它缓冲我在队列中的所有更新请求，然后我可以审核队列，如果它变得太长，我可以设置另一个实例循环发送请求？
有人发布“队列”作为答案，我会接受。

【解决方案1】：

您是否计算过解析一个提要需要多长时间？根据您检查提要更新的频率，即使是 100,000 条提要也不会让我印象深刻。您确定需要更复杂的系统吗？如果是这样，您可以考虑一个更简单的解决方案，例如将一台服务器限制为一定数量的提要，并在提要增加时向其投入更多硬件。我认为亚马逊会非常适合这一点。

【讨论】：

【解决方案2】：

似乎 OP 对队列感到满意（如果您用最终解决方案更新您的问题会很好）

【讨论】：

【解决方案3】：

我不会重叠 crons，最后会变得非常讨厌。我猜你应该有一个系统，它使用 Ajax 发送信息，多个服务器接受并呈现它，如果需要，返回操作和结果。另一方面，全球有许多可用的云解决方案，可能会更好。

【讨论】：