Стратегия для сервиса контент-агрегатора

Question

Я создал RSS, Twitter и другие агрегаторы контента для клиентов, использующих php / Mysql. Как правило, это включает в себя задание cron, некоторый анализ фида и вставку данных в базу данных для хранения и последующей повторной публикации, или удаления, или архивирования и т. Д. Ничего принципиального.

Но теперь мне поручено создать агрегаторный сервис для публичной аудитории. Я полагаю, что это нужно будет быстро масштабировать, так как каждый человек, имеющий доступ к сервису, может добавить десятки, если не сотни каналов. В течение нескольких месяцев мы можем регулярно анализировать 1000 фидов и, возможно, 100 000 в год или даже больше, если повезет.

Я думаю, что окончательная модель похожа на то, что делает Google Reader.

Итак, какова хорошая стратегия для этого? Несколько перекрывающихся крон, непрерывно работающие и читающие фиды и подключение к API для извлечения контента? Должен ли я планировать запускать несколько экземпляров Elastic Cloud или что-то еще по мере роста?

Answer 1

Вы когда-нибудь рассчитывали, сколько времени занимает анализ одного канала? В зависимости от того, как часто вы проверяете обновления фидов, даже 100 000 фидов меня не особо удивляют. Вы уверены, что нужна более сложная система? Если это так, вы можете рассмотреть более простое решение, такое как ограничение одного сервера заданным числом каналов и использование большего количества оборудования при увеличении количества каналов. Думаю, Amazon подойдет для этого.

Answer 2

Похоже, что OP был удовлетворен очередями (было бы хорошо, если бы вы обновили свой вопрос своим окончательным решением)

Answer 3

Я бы не пересекался с кронами, в конце станет очень противным. Я полагаю, у вас должна быть одна система, которая отправляет информацию с помощью Ajax, а несколько серверов принимают и обрабатывают ее, возвращая действие и результаты, если это необходимо. С другой стороны, во всем мире доступно множество облачных решений, которые могут работать даже лучше.