Какая инфраструктура должна быть для 24/7 парсера обновляющего БД?

Привет мастера.
Есть парсер, которые постоянно висит и делает много запросов на curl, плотно работая с БД. Проверка на существования сущности в БД, добавление данных, обновление и т.д.
Проблема в том, что из-за большого количества запросов запросы к АПИ сильно тормозят, пока парсер работает. Как построить архитектуру, чтобы всем было комфортно: и скорость АПИ и регулярность обновлений данных?
Решит ли проблему мастер-слейв связка? И где можно почитать про подобную инфраструктуру, для больших сайтов-парсеров, краулеров, в большим количеством данных.
  • Вопрос задан
  • 345 просмотров
Пригласить эксперта
Ответы на вопрос 3
@vitaly_il1
DevOps Consulting
Универсальный ответ - "зависит".
Нужно сделать PoC, посмотреть на запросы, оптимизировать их. Потом оценить траффик в продакшен и сделать load test. По следам это оптимизировать и масштабировать.
С точки зрения инфраструктуры - если много reads, то slave[s] очень помогут.
С точки зрения архитектуры - засылка задач в очередь и вытаскивание из нее помогают сгладить пики.
Ответ написан
hrabry
@hrabry
Посмотри в сторону https://amphp.org/, там и http клиент есть вместо CURL. Я на нём сделал демона который работает 24/7, если появляются новые запросы он обрабатывает их асинхронно. Так же реализовал возможность ограничить максимальное кол-во одновременно исходящих соединений как для всего сервера так и для отдельных источников.
У меня 1 демон с каналом связи 100мбит/c за час 4-8 млн. страниц парсит, хз много это или мало....
Ответ написан
Комментировать
romesses
@romesses
Backend инженер
Можно построить архитектуру приложений так, что API будет работать преимущественно в режиме чтения с СУБД.
А другой процесс-воркер будет получать задачи через очередь сообщений и интенсивно писать в СУБД.
В API вместо блокирующего ответ клиенту парсинга нужно сразу слать задание в очередь сообщений. Тогда соединения не будут удерживаться подолгу, а почти сразу будут закрыты по отправке в очередь.
Все, что шлется в API для добавления в очередь, можно возвращать ответ 202 (Accepted).
Как только воркер выполнит задачу, он обновит результат парсинга в БД. А тем временем, при обращении по API информация будет считана с БД без каких-либо блокирующих операций.

То есть небольшой апгрейд состоит в схеме:
APIs (write) -> MQ -> Worker(s) -> DB
APIs (read) <-> DB
Так легко добавить любой компонент в случае большой нагрузки.

Ну и, необходимо замерять нагрузку, чтобы знать где узкое горлышко.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы