В настоящее время я работаю над системой, для которой необходимо постоянно обновлять несколько URL.
Концептуально требование аналогично агрегированным новостным лентам RSS, за исключением того, что предпочтительно обновление почти в реальном времени.С точки зрения функциональности:
- пользователи могут подписаться на несколько интересующих их сборов и получать уведомления об обновлениях.
- Если пользователь действительно заинтересован, он / она может вручную инициировать повторное получение RSS-каналов, на которые он / она подписан.
У меня есть следующие ограничения:
- Количество запросов на отправку, которые я могу сделать в минуту для URL-адреса, ограничено.В противном случае я заблокирован.
- Пользователь хочет как можно более короткую задержку между фидом данных и моим сервисом агрегации для получения новостей.
- Лишь немногие URL имеют функцию обратного вызова, поэтому я должен придерживатьсяМетод извлечения.
Я могу подумать о том, чтобы несколько актеров средства извлечения представляли URL для извлечения, и каждый из этого средства извлечения допускает только одно сообщение в папке входящих для извлечения.После того, как данные извлечены, они будут переданы другому (совместно используемому) субъекту для сохранения.
Основная проблема, которую я хочу избежать, - это если есть задержка при получении данных / постоянство, если данные, полученные ранее, сохраняются позже,тогда пользователь увидит более ранние данные и данные дрейфуют вокруг.
Так что просто интересно
Является ли вышеуказанный звук разумным замыслом, гарантирующим, что данные, извлеченные первыми, будут сохраняться первыми?
Должен ли я встраивать логику персистентности в актера сборщика URL-адресов Или лучше иметь выделенного актера для персистентности?
Спасибо,