Налаштування черг завдань на 1С-Бітрікс

Налаштування черг завдань на 1С-Bitrix

Обмін з 1С падає за таймаутом, email-розсилка на 5000 підписників блокує хіт, генерація PDF-прайсу для 20 000 товарів кладе сервер. Усі ці завдання об'єднує одне: їх неможна виконувати в HTTP-запиті. Потрібна чергу — механізм, який приймає завдання, кладе в сховище та виконує в фоні через окремий процес.

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

Агенти (CAgent) — вбудована система відкладених завдань Bitrix. Агент — функція, яка викликається за розкладом. Реєстрація:

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

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

• На хітах (за замовчуванням) — при кожному запиті Bitrix перевіряє, чи є агенти, яким пора запуститися. Проблема: якщо на сайті нема трафіку — агенти не виконуються. Якщо трафік високий — перевірка агентів додає навантаження до кожного хіту.
• На 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 в Bitrix ставить завдання в чергу, Consumer — окремий PHP-демон, який слухає чергу та виконує завдання.
• Redis — через LPUSH/BRPOP. Простіше RabbitMQ, достатньо для більшості сценаріїв.

Інтеграція з Bitrix: producer реєструється як обробник подій (наприклад, OnSalePayOrder), consumer запускається через Supervisor.

Що налаштовуємо

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