内容聚合器服务策略

我为使用php/Mysql的客户端构建了RSS，Twitter和其他内容聚合器。它通常涉及一个cron作业，一些feed解析并将数据插入到数据库中以供存储和稍后重新发布，或删除或存档等。没有什么突破性的。内容聚合器服务策略

但是现在我的任务是为公众构建一个聚合器服务。我想这需要迅速扩展，因为每个有权访问该服务的人都可以添加几十个甚至几百个源数据源。在几个月内，我们可能会定期解析1000年的饲料，一年之内可能会分解1000次，或者更多的运气。

我猜最终的模型是类似谷歌读者的东西。

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

简短的回答是：队列 – zerkms 2011-12-15 22:02:43

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

2011-12-15 22:55:33

你有没有计时解析一个feed需要多长时间？根据您检查Feed更新的频率，甚至100,000条Feed也不会让我感到太过分。你确定一个更复杂的系统是必要的吗？如果是这样，您可以考虑一个更简单的解决方案，例如将一台服务器限制为一定数量的提要，并随着提要的增加向其投掷更多硬件。亚马逊对我来说会很棒。

2011-12-16 05:34:22 Julien

好像OP由队列满足（如果你与你的最终解决方案更新您的问题，这将是很好）

2012-01-04 20:12:48 zerkms

回答