Настройка очередей парсинга для больших каталогов 1С-Битрикс

Настройка очередей парсинга для больших каталогов 1С-Битрикс — задача, с которой сталкиваются при объёмах 500 000+ товаров. Парсинг 500 товаров — это простой скрипт. Парсинг 500 000 товаров — это архитектура с очередями, воркерами, мониторингом и стратегией retry. Без очередей такой каталог невозможно обработать надёжно: скрипт падает на 50 000-й позиции, и никто не знает, с какой точки продолжать. Мы гарантируем, что ваша система выдержит нагрузку и не потеряет данные. За 10 лет работы мы реализовали более 50 проектов с каталогами от 100 000 товаров — этот опыт позволяет нам сразу закладывать правильную архитектуру. Экономия бюджета на сопровождении за счёт стабильной системы составляет от $1k–3k в год.

Пример: для интернет-магазина электроники с каталогом 300 000 товаров мы спроектировали очередь на PostgreSQL, настроили 6 воркеров. Время полной обработки снизилось с 8 часов до 45 минут. Система стабильно работает более года без сбоев.

По данным PostgreSQL документации, использование SKIP LOCKED позволяет атомарно захватывать задачи без риска дедлоков.

Настройка очередей парсинга больших каталогов Битрикс: зачем это нужно

Настройка очередей парсинга каталогов Битрикс: почему это критично

Время выполнения выходит за лимиты, скрипт падает по memory limit, а повторный запуск начинается с нуля. Очередь решает эти проблемы: разбивает обработку на атомарные задачи, позволяет возобновить с места сбоя, даёт приоритет важным задачам (обновление остатков, цен).

Основные признаки, указывающие на необходимость перехода к очередям: полный цикл обработки каталога занимает больше 30 минут; скрипт периодически падает с timeout или memory limit; нельзя определить, что уже обработано после сбоя; требуется обрабатывать разные типы задач с разным приоритетом.

Как построить надёжную очередь в PostgreSQL?

Таблица-очередь в PostgreSQL — оптимальный выбор для большинства проектов на Битриксе. Надёжнее Redis (персистентность), не требует дополнительной инфраструктуры, удобно мониторить SQL-запросами. Мы используем таблицу с индексами, которые обеспечивают быстрый выбор задач по статусу и приоритету.

CREATE TABLE parser_tasks (
    id BIGSERIAL PRIMARY KEY,
    task_type VARCHAR(50) NOT NULL, -- 'parse_product', 'update_price', 'update_stock'
    payload JSONB NOT NULL, -- {'url': '...', 'element_id': 123}
    priority SMALLINT DEFAULT 5, -- 1 (высший) - 10 (низший)
    status VARCHAR(20) DEFAULT 'pending',
    worker_id VARCHAR(50), -- ID воркера, захватившего задачу
    attempts SMALLINT DEFAULT 0,
    max_attempts SMALLINT DEFAULT 3,
    error_message TEXT,
    available_at TIMESTAMP DEFAULT NOW(), -- для delayed tasks и retry
    created_at TIMESTAMP DEFAULT NOW(),
    processed_at TIMESTAMP
);
CREATE INDEX idx_pt_pick ON parser_tasks(status, priority, available_at) WHERE status IN ('pending', 'failed');

Индекс на (status, priority, available_at) — критичен для быстрого выбора следующей задачи.

Как избежать гонок при захвате задачи?

Несколько воркеров не должны взять одну задачу. Атомарный захват через SELECT ... FOR UPDATE SKIP LOCKED:

UPDATE parser_tasks
SET status = 'processing',
    worker_id = $1,
    attempts = attempts + 1
WHERE id = (
    SELECT id
    FROM parser_tasks
    WHERE status = 'pending'
      AND available_at <= NOW()
    ORDER BY priority ASC, created_at ASC
    LIMIT 1
    FOR UPDATE SKIP LOCKED
)
RETURNING *;

SKIP LOCKED — другие воркеры пропускают заблокированные строки, нет блокировок и дедлоков.

Сколько воркеров нужно запускать?

Каждый воркер — отдельный PHP-CLI процесс. Управление процессами через Supervisor:

[program:parser_worker]
command=/usr/bin/php /var/www/site/local/scripts/parser_worker.php
numprocs=4
autostart=true
autorestart=true
stderr_logfile=/var/log/parser_worker.err.log
stdout_logfile=/var/log/parser_worker.out.log

numprocs=4 — 4 параллельных воркера. Оптимальное число зависит от CPU, памяти сервера и rate limit источника. Правило: число воркеров не должно превышать допустимую нагрузку на источник (не более 1 запроса/сек на домен при 1 воркере).

Что даёт приоритизация задач?

Разные задачи имеют разный приоритет. Очереди с приоритетами позволяют критичным данным обрабатываться мгновенно, а фоновые задачи — в свободное время. Это снижает время отклика системы на изменения остатков и цен.

Остатки и цены никогда не ждут в очереди за медленным парсингом изображений.

Как мониторить состояние очереди?

Дашборд состояния в административной части:

SELECT task_type, status, COUNT(*) as cnt, AVG(EXTRACT(EPOCH FROM (processed_at - created_at))) as avg_wait_sec
FROM parser_tasks
WHERE created_at > NOW() - INTERVAL '24 hours'
GROUP BY task_type, status;

Алерт при накоплении очереди: если pending задач типа update_price больше 10 000 — значит воркеры не успевают, нужно добавить numprocs или замедлить генерацию задач.

Что входит в нашу работу?

Мы предоставляем полный цикл разработки и настройки очередей парсинга. Стоимость разработки варьируется от $500–1.5k в зависимости от сложности.

1. Проектирование схемы очереди и выбор стратегии (атомарный dequeue, retry с backoff)
2. Реализация воркера с обработчиками для каждого типа задачи
3. Настройка Supervisor и конфигурация автомасштабирования
4. Интеграция мониторинга и алертов (Grafana, Zabbix или аналоги)
5. Документация по эксплуатации и обучение вашей команды
6. Сопровождение после запуска: исправление ошибок, оптимизация производительности

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

Таймлайн работ

Итого: 4–7 рабочих дней — инфраструктурная основа для надёжной работы всей системы парсинга.