Очереди сообщений в интеграциях сайта: как выстроить устойчивый обмен

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

Зачем очереди в интеграциях сайта и где проходят границы решения

Интеграция сайта с внешней системой почти всегда означает обмен данными: заказ уходит в учётную систему, статус доставки возвращается на сайт, оплата подтверждается платёжным шлюзом. Пока внешняя система отвечает быстро, обмен выглядит простым. Проблемы начинаются, когда ответ приходит через секунды, обрывается или не приходит вовсе.

Прямой вызов внешнего сервиса из кода страницы создаёт жёсткую связь. Если сервис недоступен, посетитель видит ошибку, а данные могут потеряться. Очередь разрывает эту связь: сайт только фиксирует намерение выполнить работу, а саму работу выполняет отдельный обработчик. Пользователь получает ответ, не дожидаясь чужого сервера.

Границы решения стоит обозначить сразу. Очередь не заменяет интеграцию — она делает её устойчивее. Она не отменяет необходимость договориться о формате данных, о том, кто владелец справочников и как разрешаются конфликты. Очередь не гарантирует мгновенность: она гарантирует сохранность задачи и её повторную обработку по заданным правилам. И очередь не снимает ответственность за корректность самого обмена.

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

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

Приём события и долгая обработка: как разделить быстрый ответ и работу

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

Что фиксируем в момент события

В момент события нужно сохранить достаточно данных, чтобы обработчик мог работать без обращения к сессии пользователя. Обычно это идентификатор объекта, тип операции, полезная нагрузка, время создания и текущее состояние. Если этих данных не хватит, обработчик не сможет выполнить задачу корректно, что приведет к ошибкам.

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

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

Что делает обработчик

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

Обработчик должен быть идемпотентным: повторная обработка одной и той же задачи не должна создавать дубли. Это особенно важно, когда внешняя система приняла данные, но ответ не дошёл. Без идемпотентности повтор породит второй заказ или вторую оплату.

Ещё одно требование — предсказуемость. Обработчик не должен выполнять скрытую работу, о которой не знает заказчик. Любые изменения статусов, отправки уведомлений или работа с другими объектами должны быть описаны. Иначе разбор ошибок превращается в расследование.

Схема состояний очереди

Схема состояний — рабочий документ, по которому договариваются разработчик, аналитик и заказчик. Она показывает, какие состояния проходит задача и какие переходы между ними допустимы. Без неё невозможно понять, где задача «застряла» и что с ней делать.

Типовой набор состояний:

• Создана: задача записана, но не взята в работу.
• В обработке: задача закреплена за обработчиком.
• Выполнена: обмен завершен успешно.
• Ожидает повтора: обработка не удалась, назначена следующая попытка.
• Отложена: задача отложена по расписанию или условию.
• Окончательная ошибка: попытки исчерпаны, нужен ручной разбор.
• Отменена: задача снята до выполнения.

Переходы между состояниями должны быть явными. Например, из «в обработке» задача возвращается в «ожидает повтора» при сбое или в «выполнена» при успехе. Если обработчик упал, не завершив работу, задача не должна навсегда остаться «в обработке» — нужен механизм возврата по таймауту.

Схему удобно держать рядом с описанием интеграции и обновлять при изменении правил. Если состояние не описано, его не должно быть в системе. Лишние состояния запутывают разбор и мешают автоматизации. Хорошая схема отвечает на три вопроса: откуда задача пришла, где она сейчас и куда может уйти дальше.

Отдельно стоит продумать, что происходит с задачей, если её отменили. Отмена — это тоже переход, и он должен быть описан. Иначе отменённые задачи будут висеть в общем списке и мешать сверке.

Повторы неуспешных задач и разбор ошибок

Повторы — сердце очереди. Без них очередь превращается в журнал неудач. Но и бесконечные повторы вредны: они создают нагрузку и маскируют системную проблему.

Как настраивать повторы

Обычно повторы делают с нарастающей паузой: первая попытка быстро, следующая позже, затем ещё позже. Так временный сбой сети переживается без ручного вмешательства, а постоянная ошибка не забивает систему. Число попыток ограничивают, чтобы задача не крутилась вечно.

Разные типы ошибок требуют разного поведения. Сетевой таймаут — повод повторить. Ошибка валидации данных — повод не повторять, а отправить задачу на разбор. Смешивать их в одну стратегию нельзя: повтор бессмысленной операции только тратит ресурсы.

Полезно заранее договориться, какие ответы внешней системы считаются временной ошибкой, а какие — постоянной. Это правило фиксируется в описании интеграции и проверяется при приёмке. Без него обработчик будет повторять всё подряд.

Мёртвая очередь

Когда попытки исчерпаны, задача попадает в отдельный список — мёртвую очередь. Это не свалка, а рабочий инструмент: специалист видит, что именно не удалось, и решает, исправить данные и повторить или закрыть задачу. Без такого списка неудачные задачи теряются среди успешных.

Мёртвая очередь должна быть видимой. Если о ней никто не знает, она бесполезна. Нужен способ посмотреть содержимое, понять причину и запустить повтор после исправления. Также стоит договориться, как часто её просматривают и кто это делает.

Как выбрать вариант очереди: таблица принятия решения

Вариантов организации очереди несколько, и выбор зависит от задачи, нагрузки и ресурсов команды. Ниже — сравнение по критериям, которые важнее всего на старте.

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

Учебный пример: заказ уходит во внешнюю систему

Ниже — учебный пример. Данные условные и не описывают реальную компанию.

Входные условия

Интернет-магазин принимает заказы и передаёт их в учётную систему и в службу доставки. В сутки оформляется около 500 заказов. Внешние сервисы иногда недоступны в течение 10–15 минут. Раньше заказ отправлялся напрямую из кода оформления, и при недоступности сервиса посетитель видел ошибку, а заказ приходилось оформлять заново.

Действия

Оформление заказа разделили на два шага. Сначала сайт сохраняет заказ и создаёт задачу в очереди со статусом «создана». Посетитель сразу видит подтверждение. Затем обработчик забирает задачу, переводит её в «в обработке» и отправляет данные во внешние системы.

Если учётная система недоступна, задача переходит в «ожидает повтора» с нарастающей паузой. Если служба доставки отвечает ошибкой валидации адреса, задача уходит в «окончательная ошибка» и попадает в список на разбор. После исправления адреса специалист запускает повтор.

Наблюдаемый результат

Посетитель получает подтверждение независимо от состояния внешних сервисов. Заказы не теряются при кратких сбоях. Неудачные задачи видны в отдельном списке, и по каждой понятна причина. Повторная обработка не создаёт дублей, потому что обработчик проверяет, не был ли заказ уже передан.

Проверка результата строится на сверке: сколько задач создано, сколько выполнено, сколько в повторе и сколько в окончательной ошибке. Расхождение между числом заказов и числом успешно переданных задач — сигнал разобраться. В учебном примере такое расхождение означало бы потерю части заказов в учётной системе.

Как проверить результат и принять работу

Проверка очереди — это не один тест, а набор проверок на разных этапах. Ниже — чек-лист, по которому удобно принимать работу.

• Схема состояний описана и совпадает с поведением системы.
• Задача создаётся вместе с бизнес-объектом, без потери одного из них.
• Обработчик идемпотентен: повтор не создаёт дублей.
• Повторы настроены с нарастающей паузой и ограничением числа попыток.
• Ошибки валидации не уходят в бесконечный повтор.
• Мёртвая очередь видна и доступна для разбора.
• Зависшие задачи возвращаются из состояния «в обработке» по таймауту.
• Есть сверка числа созданных и успешно обработанных задач.
• Понятно, кто отвечает за разбор неудачных задач.
• Описан порядок возврата к прежнему поведению при сбое.

Проверять стоит не только успешный сценарий, но и поведение при недоступности внешней системы, при повторной доставке одного и того же события и при ошибке в данных. Именно эти случаи чаще всего ломают обмен. Если проверки проходят только на «хороших» данных, устойчивость очереди остаётся неподтверждённой.

Типичные ошибки и ограничения

Очередь не спасает от ошибок проектирования. Ниже — то, что встречается чаще всего.

• Прямая отправка из кода страницы без очереди. Любой сбой внешнего сервиса виден посетителю.
• Отсутствие идемпотентности. Повтор создаёт дубли заказов или оплат.
• Бесконечные повторы без ограничения. Система забивается задачами, которые не могут выполниться.
• Смешивание временных и постоянных ошибок. Валидационные ошибки уходят в повтор и не разбираются.
• Задачи, навсегда застрявшие «в обработке». Нет возврата по таймауту.
• Невидимая мёртвая очередь. О неудачах никто не знает.
• Отсутствие сверки. Расхождение между заказами и задачами замечают слишком поздно.

Ограничения тоже стоит назвать честно. Очередь добавляет задержку: результат обмена приходит не мгновенно. Она требует сопровождения: кто-то должен следить за мёртвой очередью и разбирать ошибки. Она не устраняет причины сбоев во внешних системах. И она не заменяет договорённости о формате данных и владельцах справочников.

Есть и организационное ограничение. Очередь работает только тогда, когда есть ответственный за её состояние. Если после запуска никто не смотрит на неудачные задачи, польза от очереди снижается до нуля. Поэтому вопрос сопровождения стоит решать до запуска, а не после.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужны конкретные вводные. Без них любая оценка будет приблизительной.

• Какие события уходят во внешние системы и как часто.
• Какие внешние системы участвуют и как они отвечают при сбое.
• Допустимое время задержки между событием и обработкой.
• Что считается успехом, а что — ошибкой, требующей разбора.
• Кто владелец данных и как разрешаются конфликты.
• Есть ли требования к журналированию и хранению истории задач.
• Кто будет сопровождать очередь после запуска.
• Какие ограничения у текущей платформы сайта.

Отдельно стоит уточнить, как платформа уже умеет работать с очередями. Например, в «1С-Битрикс» есть модуль Push and Pull, который может использовать сервер очередей — локальный или облачный. В настройках модуля выбирается тип сервера. Устаревшие версии серверов очередей могут не поддерживаться в актуальных релизах. Это влияет на выбор варианта, но не отменяет общих принципов.

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

FAQ