我使用 php/Mysql 为客户构建了 RSS、twitter 和其他内容聚合器。它通常涉及一个 cron 作业，一些提要解析并将数据插入数据库以供存储和稍后重新发布、删除或存档等。没有什么突破性的。
但现在我的任务是为公众构建一个聚合器服务。我想这将需要快速扩展，因为每个有权访问该服务的人都可以添加数十个(如果不是数百个)源提要。在几个月内，我们可能会定期解析 1000 个提要，一年内可能会解析 100,000 个，如果运气好的话，可能会更多。
我想最终模型类似于谷歌阅读器所做的。
那么，什么是好的策略呢？多个重叠的 crons，持续运行和阅读提要并连接到 API 以提取内容？我应该计划运行 Elastic Cloud 的多个实例还是随着需求的增长而运行？
最佳答案
您是否计算过解析一个提要需要多长时间？根据您检查 feed 更新的频率，即使 100,000 个 feed 也不会让我觉得太多。您确定需要更复杂的系统吗？如果是，您可以考虑一个更简单的解决方案，例如将一台服务器限制为一定数量的提要，并在提要增加时为其配备更多硬件。我认为亚马逊会非常适合这一点。
关于php - 内容聚合服务策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8527226/