我使用php / Mysql为客户构建了RSS，Twitter和其他内容聚合器。它通常涉及一个cron作业，一些feed解析和插入数据到数据库中以便存储和以后重新发布，删除或存档等等。没有什么是开创性的。
但现在我的任务是为公众提供聚合服务。我想这需要快速扩展，因为每个有权访问该服务的人都可以添加数十个（如果不是数百个）源代码。在几个月内，我们可能会定期解析1000个饲料，一年内可能会解冻100,000个，或者更幸运。
我猜最终模型类似于谷歌阅读器的功能。
那么，对此有什么好的策略？多个重叠的crons，持续运行和读取feed并连接到API来提取内容？我是否应该计划运行多个Elastic Cloud实例或者根据需要增长？
答案 0 :(得分：1)
您有没有计划解析一个Feed需要多长时间？根据您检查Feed更新的频率，甚至100,000个Feed也不会让我感觉太多。你确定需要一个更复杂的系统吗？如果是，您可以考虑一个更简单的解决方案，例如将一台服务器限制为一定数量的Feed，并在您的Feed增加时向其投入更多硬件。我认为亚马逊会很棒。
答案 1 :(得分：0)
我不会重叠crons，最后会变得非常讨厌。我想你应该有一个系统用Ajax发送信息，多个服务器接受并呈现它，如果需要，返回动作和结果。 另一方面，全球有许多云解决方案，可能会更好。