Налаштування черг парсингу для великих каталогів 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 робочих днів — інфраструктурна основа для надійної роботи всієї системи парсингу.