0

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

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

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

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

4

3 回答 3

1

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

于 2012-01-04T20:12:48.217 回答
1

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

于 2011-12-16T05:34:22.280 回答
0

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

于 2011-12-15T22:55:33.653 回答