Стратегия для сервиса контент-агрегатора
Я создал RSS, Twitter и другие агрегаторы контента для клиентов, использующих php/Mysql. Как правило, он включает в себя задание cron, некоторый разбор фидов и вставку данных в базу данных для хранения и последующей повторной публикации, или удаления, или архивирования и т. Д. Ничего принципиального.
Но теперь передо мной стоит задача создать сервис-агрегатор для публичной аудитории. Я полагаю, что это нужно будет быстро масштабировать, так как каждый человек, имеющий доступ к сервису, может добавить десятки, если не сотни каналов. В течение нескольких месяцев мы можем регулярно анализировать 1000 фидов и, возможно, 100 000 в год, или больше, если повезет.
Я думаю, что окончательная модель похожа на то, что делает Google Reader.
Итак, что является хорошей стратегией для этого? Несколько перекрывающихся крон, непрерывно работающие и читающие каналы, а также подключение к API для извлечения контента? Должен ли я планировать запуск нескольких экземпляров Elastic Cloud или чего-то еще по мере необходимости?
3 ответа
Вы когда-нибудь рассчитывали, сколько времени занимает разбор одного канала? В зависимости от того, как часто вы проверяете обновления фидов, даже 100 000 фидов меня не особо удивляют. Вы уверены, что нужна более сложная система? Если это так, вы можете рассмотреть более простое решение, такое как ограничение одного сервера заданным количеством каналов и использование большего количества оборудования при увеличении количества каналов. Я думаю, что Amazon отлично подойдет для этого.
Похоже, что OP был удовлетворен очередями (было бы хорошо, если бы вы обновили свой вопрос своим окончательным решением)
Я бы не стал пересекать кроны, в конце получится очень противно. Я полагаю, у вас должна быть одна система, которая отправляет информацию с помощью Ajax, а несколько серверов принимают и обрабатывают ее, возвращая при необходимости действие и результаты. С другой стороны, во всем мире доступно множество облачных решений, которые могут работать еще лучше.