Перейти к содержанию

Очереди сообщений

Очередь — буфер, который накапливает сообщения и сохраняет их до момента, когда их заберут для обработки. Это центральный механизм асинхронной модели обмена: пока сообщение в очереди, оно не потеряно, даже если потребитель временно недоступен.

В DataHUB понятие очереди живёт в трёх разных местах и решает в каждом близкую, но не одинаковую задачу.

Три места очередей

Очередь шины — то, что физически реализовано в RabbitMQ. Шина для каждой системы-приёмника держит свою очередь, в которую попадают копии адресованных ей сообщений. Очередь шины — между источником и приёмником.

Очередь исходящих в модуле источника — внутренний пул сообщений, сформированных, но ещё не отправленных в шину. Сюда обработчик кладёт сформированное сообщение, отдельный поток забирает и шлёт в API шины.

Локальный пул входящих в модуле приёмника — внутренний пул принятых из шины сообщений, ещё не применённых к бизнес-данным. Сюда транспорт модуля кладёт принятое сообщение и сразу подтверждает приём шине; отдельный поток затем берёт сообщение из пула и применяет обработчиком.

Все три — концептуально очереди (буферизуют, упорядочивают, развязывают по времени), но решают разные задачи и живут в разных слоях.

Зачем очередь нужна

В любом из трёх мест очередь решает один и тот же набор задач:

Сглаживание скоростей. Поставщик данных может выкладывать сообщения быстрее, чем потребитель успевает их обрабатывать. Без очереди поставщик упирался бы в скорость самого медленного потребителя; с очередью — работает в своей скорости, а сообщения копятся буфером.

Развязка по времени. Потребитель может быть временно недоступен (плановое обновление, рестарт, инцидент). Сообщения накапливаются и доставляются, как только связь восстановится. Поставщик про эту недоступность не знает.

Гарантия неутраты. Сообщение, попавшее в очередь, не удаляется до того, как кто-то подтвердит его успешный приём или обработку. Сбой потребителя посередине → сообщение возвращается и пойдёт снова.

Очередь на получателя в шине

Базовый принцип шины: у каждой системы-приёмника — своя очередь. Сообщения для разных приёмников не перемешиваются. Веерная рассылка одного сообщения нескольким приёмникам — это столько физических копий, сколько приёмников.

Это позволяет каждому приёмнику работать в своём темпе, не задерживая остальных. Трафик и место на дисках шины растут линейно с числом подписчиков — компромисс осознанный.

Свойства очередей

Упорядоченность внутри очереди. Сообщения внутри одной очереди выдаются в том порядке, в каком были положены. Это важно для документооборота: «создать → изменить → отменить» одного документа должны прийти в этой последовательности.

Глобальной упорядоченности нет. Сообщения в разных очередях не сравнимы по порядку. Глобальный порядок для большинства интеграционных сценариев не нужен и стоил бы значительной потери производительности.

Персистентность. Очереди и сообщения переживают перезапуск сервиса, в котором они живут. Положенное в очередь утром останется в ней до вечера даже при перезагрузках.

Долговечность сообщения. Сообщение остаётся в очереди до явного подтверждения. Никаких автоматических TTL у штатных очередей шины по умолчанию нет — лучше пусть полежит, чем потеряется.

Что НЕ хранится в очередях

  • История доставленных сообщений. После подтверждения сообщение из очереди удаляется. Никакого централизованного «лога доставки» в БД шины нет — содержимое дальше живёт только в системе-получателе. Статус прохождения видит клиентский модуль (в типовом 1С-модуле — отдельная страница со статусами).
  • Метаданные о компаниях, системах, маршрутах. Они в БД шины, не в очереди.
  • Файловые вложения. В сообщении лежит ссылка на файл, сам файл — отдельно (см. Обмен файлами).

Что дальше