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

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

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

Черга завдань — критичний елемент highload-проєктів. Без неї кожен довгий процес блокує користувацькі запити, а таймаути призводять до втрати даних. Правильна черга вирішує три проблеми: гарантує виконання, дозволяє паралельно обробляти сотні завдань і дає механізм retry для збійних операцій. У Бітрікс для цього є кілька шляхів: від простих агентів до зовнішніх брокерів на кшталт RabbitMQ.

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

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

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

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

• На хітах (за замовчуванням) — при кожному запиті Бітрікс перевіряє, чи є агенти, яким пора запуститися. Проблема: якщо на сайті немає трафіку — агенти не виконуються. Якщо трафік високий — перевірка агентів додає навантаження до кожного хіту.
• На cron — рекомендований режим. Винесення агентів на cron знижує навантаження. У crontab додається рядок: */5 * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. Параметр у .settings.php:

'agents' => [ 'value' => [ 'use_crontab' => true ] ] 

Чому агенти на хітах — це погано?

Агенти на хітах — основна причина падіння продуктивності середніх проєктів. Ми спеціалізуємося на налаштуванні агентів Бітрікс, і знижуємо навантаження до 70%. Кожен HTTP-запит витрачає до 10% часу на перевірку та запуск агентів. При 10 000 відвідувачів на день це призводить до зайвих 20 000 викликів CAgent::CheckAgents() на годину. Переведення на cron знижує навантаження на сервер до 70% і гарантує виконання навіть при нульовому трафіку. Агенти на cron працюють у 2 рази швидше, ніж на хітах.

Коли агентів недостатньо?

Агенти — однопотокові. Один агент виконується, інші чекають. Якщо агент імпорту даних працює 10 хвилин — усі інші агенти (відправлення листів, перерахунок кешу, обмін з 1С) затримуються. Для проєктів з інтенсивною фоновою обробкою — потрібна повноцінна черга. Фонові процеси Бітрікс потребують черги для масштабування.

Черга на базі highload-блока

Найпростіша реалізація без зовнішніх залежностей. 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']). Використовуйте D7 ORM — це стандарт для Бітрікс. Черга повідомлень D7 реалізується через HL-блок.
3. Обробник (cron-скрипт) — запускається щохвилини, вибирає N завдань зі статусом pending, переводить в processing, виконує, позначає done або failed.

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

Як налаштувати чергу на HL-блоці: покрокова інструкція

1. Створіть HL-блок QueueJob з полями: UF_HANDLER (рядок), UF_PAYLOAD (текст), UF_STATUS (список: pending, processing, done, failed), UF_ATTEMPTS (число), UF_CREATED_AT (дата), UF_PROCESSED_AT (дата).
2. Додайте індекс на поле UF_STATUS для швидкої вибірки pending-завдань.
3. Напишіть клас-обробник з методом run($payload), який повертає true/false.
4. Створіть cron-скрипт, який щохвилини вибирає до 10 завдань зі статусом pending, переводить їх в processing, викликає обробник, і при успіху позначає done, при помилці — failed з інкрементом attempts.
5. Захистіть скрипт від паралельного запуску через flock.

Зовнішні брокери: RabbitMQ, Redis

Для високонавантажених проєктів:

• RabbitMQ — підключення через php-amqplib. Producer в Бітрікс ставить задачу в чергу, Consumer — окремий PHP-демон, який слухає чергу і виконує завдання. Пропускна здатність — до 10 000 завдань на хвилину. RabbitMQ для Бітрікс дає максимальну продуктивність. Для RabbitMQ варто налаштувати dead letter exchange для невдачних завдань. Публікація завдань реалізується через publish/subscribe pattern.
• Redis — через LPUSH/BRPOP. Простіший за RabbitMQ, достатній для більшості сценаріїв. Інтеграція з Бітрікс: producer реєструється як обробник події (наприклад, OnSalePayOrder), consumer запускається через Supervisor. При високому навантаженні застосовується backpressure для регулювання швидкості producer. Supervisor для Бітрікс забезпечує безперервну роботу consumer.

Як обрати брокер черг?

Рішення залежить від навантаження. Оптимізація продуктивності Бітрікс неможлива без винесення агентів, а вибір брокера — наступний крок.