Настройка очередей задач на 1С-Битрикс

Настройка очередей задач на 1С-Битрикс

Обмен с 1С падает по таймауту, email-рассылка на 5000 подписчиков блокирует хит, генерация PDF-прайса для 20 000 товаров кладёт сервер. Все эти задачи объединяет одно: их нельзя выполнять в HTTP-запросе. Нужна очередь — механизм, который принимает задачу, кладёт в хранилище и выполняет в фоне через отдельный процесс.

Штатные механизмы: агенты

Агенты (CAgent) — встроенная система отложенных задач Битрикс. Агент — функция, которая вызывается по расписанию. Регистрация:

CAgent::AddAgent(
    "MyClass::processQueue();",  // PHP-код для выполнения
    "main",                       // модуль
    "N",                          // не периодический (N) или периодический (Y)
    300,                          // интервал в секундах
    "",                           // дата первой проверки
    "Y",                          // активность
    ""                            // дата первого запуска
);

Агенты выполняются двумя способами:

• На хитах (по умолчанию) — при каждом запросе Битрикс проверяет, есть ли агенты, которым пора запуститься. Проблема: если на сайте нет трафика — агенты не выполняются. Если трафик высокий — проверка агентов добавляет нагрузку к каждому хиту.
• На cron — рекомендуемый режим. В crontab добавляется строка: */5 * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. Параметр в .settings.php: 'agents' => ['use_crontab' => true].

Когда агентов недостаточно

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

Для проектов с интенсивной фоновой обработкой — нужна полноценная очередь.

Очередь на базе highload-блока

Простейшая реализация без внешних зависимостей:

1. HL-блок QueueJob — поля: UF_HANDLER (класс-обработчик), UF_PAYLOAD (JSON с параметрами), UF_STATUS (pending/processing/done/failed), UF_ATTEMPTS (количество попыток), UF_CREATED_AT, UF_PROCESSED_AT.
2. Постановка задачи — QueueJobTable::add(['UF_HANDLER' => 'ImportHandler', 'UF_PAYLOAD' => json_encode($data), 'UF_STATUS' => 'pending']).
3. Обработчик (cron-скрипт) — запускается каждую минуту, выбирает N задач со статусом pending, переводит в processing, выполняет, помечает done или failed.

Преимущества: retry (повторные попытки по UF_ATTEMPTS), мониторинг (SQL-запрос к HL-блоку), приоритеты (добавить поле UF_PRIORITY).

Очередь через модуль messagequeue (D7)

В ядре D7 есть экспериментальный модуль для работы с очередями: Bitrix\Main\Config\Queue. Поддерживает драйверы: file (файловая очередь), database (таблица БД). Конфигурация в .settings.php:

'queue' => [
    'value' => [
        'default' => [
            'driver' => 'database',
            'table' => 'b_queue_message',
        ],
    ],
],

На практике этот модуль используется редко — документации мало, а функциональность ограничена. Для production рекомендуется либо HL-блок (просто и надёжно), либо внешний брокер.

Внешние брокеры: RabbitMQ, Redis

Для высоконагруженных проектов:

• RabbitMQ — подключение через php-amqplib. Producer в Битрикс ставит задачу в очередь, Consumer — отдельный PHP-демон, который слушает очередь и выполняет задачи.
• Redis — через LPUSH/BRPOP. Проще RabbitMQ, достаточно для большинства сценариев.

Интеграция с Битрикс: producer регистрируется как обработчик события (например, OnSalePayOrder), consumer запускается через Supervisor.

Что настраиваем

• Перевод агентов на cron (вынос из хитов)
• Проектирование очереди задач на HL-блоке с retry и мониторингом
• Cron-скрипт обработчика очереди с защитой от параллельного запуска (flock)
• Настройка Supervisor для PHP-consumer (при использовании RabbitMQ/Redis)
• Мониторинг: алерт при росте необработанных задач
• Тестирование: постановка задачи, обработка, retry при ошибке