Задать вопрос

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

Привет мастера.
Есть парсер, которые постоянно висит и делает много запросов на curl, плотно работая с БД. Проверка на существования сущности в БД, добавление данных, обновление и т.д.
Проблема в том, что из-за большого количества запросов запросы к АПИ сильно тормозят, пока парсер работает. Как построить архитектуру, чтобы всем было комфортно: и скорость АПИ и регулярность обновлений данных?
Решит ли проблему мастер-слейв связка? И где можно почитать про подобную инфраструктуру, для больших сайтов-парсеров, краулеров, в большим количеством данных.
  • Вопрос задан
  • 349 просмотров
Подписаться 4 Простой 4 комментария
Пригласить эксперта
Ответы на вопрос 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
Так легко добавить любой компонент в случае большой нагрузки.

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

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

Похожие вопросы
Алабуга Москва
До 370 000 ₽
Betnetix Ростов-на-Дону
от 80 000 до 250 000 ₽
Strikt Москва
от 100 000 до 180 000 ₽