Система с гарантированной доставкой сообщений: очереди, outbox и повторы без дублей

Сеть не отличает потерянное сообщение от потерянного ответа, поэтому выбрать «не терять и не повторять» нельзя. Для данных, которые нельзя терять (заказы, изменения остатков, документы), берётся схема «доставить хотя бы раз» и поверх неё защита от дублей. Эффект «ровно один раз» получается из двух частей: отправитель повторяет до подтверждения, а получатель узнаёт то, что уже обработал.

Три уровня гарантии и что за каждый платите

• «Не больше одного раза». Отправили и забыли. Просто и быстро, но сообщения теряются. Годится для сведений, которые устареют через минуту: индикатор онлайна, показания, которые придут снова.
• «Хотя бы один раз». Повторяем до подтверждения. Сообщения не теряются, но могут прийти дважды. Это основная схема для бизнес-данных.
• «Один раз по эффекту». «Хотя бы раз» плюс получатель, который не выполняет повтор. Стоит дороже всего: нужны идентификаторы, хранилище обработанных, дисциплина в коде.

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

Что такое outbox и зачем он нужен

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

Цена небольшая: одна таблица, один процесс-отправитель и дубли при повторах, которые закрывает получатель. Зато исчезает класс ошибок «заказ есть, сообщения нет». Выбор между очередью и событиями в архитектуре в целом описан на странице про микросервисы и высоконагруженные системы; здесь разбираем сам обмен.

Как получатель узнаёт повтор

Защита от дублей лежит на получателе: отправитель может только повторять. Получатель записывает идентификатор сообщения в базу в той же транзакции, что и результат, и повтор находит запись и возвращает прежний итог. Где есть бизнес-ключ, например номер заказа партнёра, дубль отсекает ограничение базы на повтор значения. Для передачи состояния хватает номера версии, а простые операции делаются так, чтобы повтор был безвреден: «установить статус», а не «изменить статус». Какой приём где, решаем по каждому типу сообщений.

Как повторяем и когда сдаёмся

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

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

Экран разбора для человека

Человек, а не программист, должен видеть для каждого типа сообщения: что застряло, с какого времени, по какой причине и что можно сделать. Минимальный набор: список с фильтром по типу и возрасту, текст причины понятным языком, кнопки «повторить» и «отклонить с комментарием». Обмен с партнёрами в форматах оператора и AS2 вынесен отдельно, см. страницу про EDI-интеграции; здесь речь об обмене между вашими собственными системами и сервисами.

Сверка как последняя линия обороны

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

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

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