Очереди сообщений
Компонент Bitrix\Main\Messenger (с main 25.100.300) реализует асинхронные очереди сообщений с настраиваемой стратегией повторов (retry_strategy). Для стабильной работы на проде обработку сообщений переводят в фоновый режим CLI (run_mode => cli) под управлением супервизора, предотвращая блокировку воркеров PHP-FPM во время пользовательских запросов.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Настройка очередей
-
2
Отправка сообщений
-
3
Обработка сообщений
Материалы
Официальная документация
Проверь себя
Заказ создан, а в CRM его нет, и повторной попытки не было. Обработчик очереди написан «аккуратно», с try-catch. Где ошибка?
В try-catch: process() вернул void, и сообщение считается обработанным. Чтобы сработал retry_strategy, исключение должно вылететь наружу — RecoverableMessageException для временной ошибки или любое другое.
Днём очередь разбирается, ночью сообщения копятся до утра. Почему?
Режим run_mode web: Worker::process() ставится фоновой задачей на каждый хит и работает только после ответов посетителям. Без трафика очередь стоит. Для прода — cli с messenger:consume под supervisor.
Чем очередь отличается от агента и фоновой задачи, если все трое «делают в фоне»?
Фоновая задача выполняется после ответа в том же процессе и без гарантии; агент — по расписанию, без повторов и приоритетов; очередь хранит сообщение в таблице, повторяет по retry_strategy и разбирается независимо от хита.
Что сломается, если в сообщение положить только ID задачи, которую надо отправить во внешний сервис при удалении?
К моменту обработки задача уже удалена, и внешний идентификатор взять неоткуда. В сообщение кладут все данные, нужные обработчику, а не ссылку на сущность.
Не сходится?
Спросите ассистента BXMax: он знает документацию и материалы сайта по этой теме.
Знаете материал лучше?
Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить