Очереди и пакетная обработка в интеграциях: как не перегружать сайт

Очереди и пакетная обработка данных в интеграциях

Интеграция часто работает нормально на сотне объектов и начинает ломаться на десятках тысяч. Причина не обязательно в API или сервере: проблема может быть в самом подходе, когда весь обмен пытаются выполнить одним длинным HTTP-запросом.

Очереди и пакетная обработка позволяют разбить большую задачу на контролируемые части, ограничить нагрузку и продолжить работу после временной ошибки без повторной обработки всего объёма.

Почему один большой импорт опасен

Длинный процесс упирается в время выполнения PHP, память, ограничения внешнего API и нестабильность сети. Если ошибка возникает на 95% обработки, без сохранения прогресса приходится запускать всё заново.

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

Что даёт очередь

Вместо команды «обработать 50 000 товаров» система создаёт набор небольших задач. Воркер берёт их последовательно или небольшим числом параллельных процессов. Каждая задача знает собственный статус, количество попыток и результат.

Если одна позиция содержит ошибочные данные, она не должна останавливать весь импорт. Её можно перевести в ошибку, сохранить причину и продолжить обработку остальных объектов.

Как выбрать размер пакета

Универсального числа нет. Пакет зависит от тяжести операции, скорости API и возможностей сервера. Для одной интеграции удобно обрабатывать по 100 объектов, для другой — по 10. Хороший размер тот, при котором задача выполняется предсказуемо и не превышает лимиты ресурсов.

Не запускайте слишком много параллельных воркеров

Параллельность ускоряет обмен только до определённого момента. После этого база, диск или внешний API становятся узким местом. Если сервис разрешает 10 запросов в секунду, двадцать воркеров не сделают обмен в два раза быстрее — они скорее начнут получать ограничения и retry.

Что должно храниться у задачи

тип операции;
идентификатор объекта или пакета;
статус обработки;
время создания и последней попытки;
количество попыток;
текст последней ошибки;
данные, необходимые для безопасного повторного запуска.

Как запускать очередь

Для фоновой обработки обычно используют cron или отдельный worker. Важно не привязывать тяжёлую интеграцию к открытию страницы пользователем. Публичный запрос может поставить задачу в очередь и быстро вернуть ответ, а реальная синхронизация выполнится в фоне.

Контроль прогресса важен не меньше скорости

Администратор должен понимать, сколько задач ожидает обработки, сколько завершено и сколько упало с ошибкой. Без такой статистики очередь превращается в «чёрный ящик»: кажется, что обмен работает, пока кто-то не замечает устаревшие данные.

Большой обмен становится устойчивым не тогда, когда выполняется быстро, а когда умеет продолжаться после частичного сбоя.

Архитектура очереди особенно полезна для обменов с каталогами, CRM, маркетплейсами и внешними API. Общие принципы интеграции описаны в статье о проектировании API-обменов.

Если существующий обмен периодически зависает или падает на больших объёмах, его можно переработать в рамках технической поддержки сайта.