Очереди обмена данными: как избежать потери документов и заказов

Почему асинхронный обмен не защищает от потерь сам по себе — и что защищает

Материал будет полезен тем, кто отвечает за интеграцию учётной системы, сайта, CRM или склада с внешними сервисами: маркетплейсами, ЭДО, партнёрскими API — и время от времени сталкивается с ситуацией «заказ был, а в системе его нет» или «документ ушёл, но контрагент его не получил». Разбираемся, почему так происходит, какие технические решения снимают этот риск и какие вопросы стоит задать себе (или подрядчику) до того, как обмен данными станет узким местом бизнеса.

Что такое очередь обмена данными простыми словами

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

Очередь vs прямой вызов API

Разница с прямым вызовом («запрос — ответ») принципиальна. При прямом вызове, если получатель недоступен, отправитель сразу видит ошибку и должен сам решать, что делать: повторить попытку, отложить, потерять данные. Очередь снимает эту проблему: сообщение остаётся на хранении, пока получатель не восстановится и не заберёт его, а отправитель может продолжать работу, не дожидаясь ответа. Именно поэтому очереди — стандартный инструмент там, где системы должны быть слабо связаны (loosely coupled) и переживать временную недоступность друг друга без потери данных.

Модели «очередь» и «издатель — подписчик»

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

Как устроена надёжная доставка

Подтверждения: publisher confirm и consumer acknowledgement

Ключевая идея, вокруг которой строится вся надёжность очередей, — подтверждения. Они нужны в двух точках канала. Во-первых, брокер должен подтвердить отправителю, что сообщение действительно принято и сохранено — этот механизм в терминологии RabbitMQ называется publisher confirm. Во-вторых, брокер должен получить подтверждение от получателя, что сообщение обработано, прежде чем считать его удалённым из очереди — это consumer acknowledgement.

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

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

At-least-once, at-most-once, exactly-once — что реально бывает

Практически все брокеры сообщений опираются на одну из двух базовых стратегий доставки. Большинство брокеров поддерживают доставку хотя бы раз (at-least-once) или максимум раз (at-most-once); первая может привести к дубликатам, вторая — к потере сообщений, и обе требуют тщательного мониторинга. На практике для документов и заказов почти всегда выбирают at-least-once: потерять сообщение хуже, чем обработать его дважды, если у обработчика есть защита от дублей.

Модель «ровно один раз» (exactly-once) в чистом виде между независимыми системами практически недостижима — её обычно эмулируют комбинацией at-least-once доставки и идемпотентной обработки на стороне получателя, а не гарантируют на уровне транспорта.

Идемпотентность: почему дубликат не должен быть страшен

Раз повторная доставка сообщения — нормальный сценарий, а не исключение, обработчик должен уметь получить одно и то же сообщение дважды и не создать два заказа или два документа вместо одного. Это называется идемпотентностью. На практике это делается через уникальный идентификатор сообщения (idempotency key), который сохраняется вместе с результатом обработки: если сообщение с таким же id уже обработано, повторная обработка просто пропускается или возвращает тот же результат.

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

Dead Letter Queue: куда деваются «зависшие» сообщения

Если сообщение раз за разом не удаётся обработать — например, из-за некорректного формата документа или временно недоступного получателя — бесконечные повторы либо блокируют очередь, либо перегружают систему. Для этого используется отдельная очередь недоставленных сообщений (Dead Letter Queue, DLQ). Без DLQ поведение системы опасно в любом случае: «отравленное» сообщение, которое всегда завершается ошибкой, продолжает повторно доставляться, блокируя обработку здоровых сообщений позади него (head-of-line blocking), а если сбои отбрасываются без записи, теряется видимость багов, несовпадений схем и проблем выше по цепочке (silent data loss).

DLQ — не «свалка», а рабочая зона для разбора: после того как сообщение попало в DLQ, «отбросить» его всё равно должно быть осознанным действием, а не результатом небрежности, поэтому на DLQ стоит устанавливать свой срок хранения и настраивать оповещения по глубине и возрасту очереди, чтобы сбои разбирались, а не исчезали молча. Важный нюанс: если сообщение вернули из DLQ на повторную обработку (replay), это тоже повторная доставка — и здесь снова нужна идемпотентность обработчика.

Transactional Outbox: как не потерять событие при сбое между БД и брокером

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

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

Решает эту проблему паттерн Transactional Outbox: вместо прямой отправки в брокер, сообщение сохраняется в отдельной таблице outbox в той же транзакции базы данных, что и сам заказ. Это использует гарантию атомарности реляционной БД: либо коммитится и заказ, и запись в outbox, либо не коммитится ничего — а отдельный процесс (relay) затем читает таблицу outbox и публикует сообщения в брокер, повторяя отправку при сбоях.

Из этого следует важное практическое ограничение: Transactional Outbox по своей природе даёт доставку at-least-once — при сбое relay-процесс может повторно отправить то же сообщение, поэтому получатель должен быть готов к дубликатам и оставаться идемпотентным. Это ещё раз показывает, что все перечисленные механизмы работают не по отдельности, а как единый комплект.

Российская специфика

Обмен данными в 1С: план обмена и его слабые места

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

На практике потери и «зависания» документов в обменах 1С почти всегда возникают не в самом механизме, а в его эксплуатации. Частая причина — остановка регламентного задания, которое запускает синхронизацию: обмен данными обычно запускается автоматически по расписанию каждые 15–30 минут, но задание может остановиться по разным причинам — сервер перезагрузился и задание не запустилось, кто-то случайно отключил его в настройках, или задание завершилось с ошибкой и больше не пытается повториться.

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

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

Для складских и торговых сценариев это особенно ощутимо: 80% проблем с обменом данными на практике возникает не из-за «кривого кода», а из-за организационных и архитектурных просчётов — например, склад отгружает товар, а документ реализации в учётной системе появляется только через несколько часов после пакетной выгрузки, и за это время менеджер успевает продать те же единицы другому клиенту.

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

Электронный документооборот (ЭДО): отдельный правовой слой

Если речь идёт не о синхронизации данных между своими системами, а о юридически значимом обмене документами с контрагентами и государством (счета-фактуры, УПД, накладные), в игру вступает отдельный правовой контур, который очередями сообщений напрямую не регулируется. Единого закона, регулирующего электронный документооборот в РФ, нет — есть ряд нормативных актов, среди которых базовым считается Федеральный закон № 63-ФЗ «Об электронной подписи», регулирующий применение электронной подписи и юридическую силу документов.

К нему добавляются требования 149-ФЗ «Об информации, информационных технологиях и о защите информации» в части хранения и передачи данных, а также нормы о бухгалтерском учёте — если в электронный вид переводятся первичные документы, компании необходимо отразить это в учётной политике.

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

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

Другими словами, в ЭДО «доставлено» и «юридически значимо доставлено» — не одно и то же, и это стоит учитывать отдельно от чисто технической надёжности канала.

Заказы с маркетплейсов: где на самом деле теряются данные

Для интеграций с Ozon, Wildberries, Яндекс Маркетом и другими площадками физическая потеря сообщения — редкий случай: и площадка, и учётная система обычно предоставляют REST API с понятным протоколом запросов. Куда чаще происходит не потеря, а рассинхронизация статусов и остатков между площадкой и учётной системой, которая по последствиям неотличима от потери заказа.

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

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

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

Российские очереди сообщений и брокеры

Для построения собственной интеграции с гарантированной доставкой в России доступны как классические брокеры с открытым кодом (RabbitMQ, Kafka), так и облачные сервисы очередей от российских провайдеров. В частности, есть готовые SQS-совместимые облачные очереди с библиотеками именно под 1С: на примере такого брокера от российского облачного провайдера очереди сообщений применяются как инструмент обмена данными между системами, а свободно распространяемая библиотека для 1С упрощает работу с этим и другими SQS-совместимыми сервисами.

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

Варианты реализации интеграции

На практике задачу «не терять документы и заказы при обмене данными» решают тремя принципиально разными путями.

Готовые сервисы-коннекторы. SaaS-решения для синхронизации заказов и остатков между маркетплейсами и учётной системой (МойСклад, различные no-code интеграторы и специализированные сервисы для продавцов). Быстрый старт, минимум разработки, но ограниченная гибкость логики сопоставления статусов и не всегда прозрачный механизм повторов при сбоях на стороне площадки.

Брокер сообщений общего назначения. RabbitMQ, Kafka или облачная очередь как транспортный слой между собственными сервисами или между учётной системой и внешним API. Даёт полный контроль над подтверждениями, DLQ и идемпотентностью, но требует инженерных ресурсов на разработку и последующую поддержку — мониторинг, обработка исключений, повторные доставки.

Механизмы платформы 1С. План обмена, распределённые информационные базы (РИБ), 1С-ЭДО и отраслевые шины на 1С — там, где основной ландшафт уже построен на 1С и не требуется интеграция с внешними высоконагруженными системами за пределами экосистемы.

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

Практические этапы внедрения

1. Зафиксировать, что именно нельзя терять. Не всякий обмен требует одинаковой строгости: потеря аналитического события — не то же самое, что потеря заказа или счёта-фактуры. Список критичных типов документов и заказов определяет, где обязательны подтверждения, DLQ и idempotency-ключи, а где достаточно базовой синхронизации.
2. Выбрать модель доставки и включить подтверждения на обоих концах канала. Если используется брокер сообщений — включить publisher confirms и consumer acknowledgements, а не полагаться на настройки по умолчанию.
3. Спроектировать идемпотентность обработчиков. Договориться о формате уникального идентификатора сообщения (заказа, документа) и хранить историю уже обработанных идентификаторов там, где повторная обработка недопустима.
4. Настроить DLQ и мониторинг её глубины. Определить, кто отвечает за разбор недоставленных сообщений, и установить оповещения по количеству и возрасту сообщений в DLQ, а не полагаться на ручные проверки.
5. Для сценариев «запись в БД + отправка события» — предусмотреть outbox-таблицу или аналогичный механизм атомарной публикации, если критично, чтобы событие не потерялось при сбое между сохранением данных и их отправкой.
6. Протестировать сценарии сбоя, а не только штатный путь. Отключить получателя во время обмена, сэмулировать дубликат сообщения, оборвать соединение в момент подтверждения — и проверить, что система ведёт себя предсказуемо.
7. Организовать выборочную сверку на старте. Особенно для 1С-обменов и интеграций с маркетплейсами: первые недели параллельно сверять часть документов и заказов вручную, чтобы поймать «тихие» потери, которые не видны по логам.

Ограничения, ошибки и риски

• Ставка только на «очередь» без подтверждений и DLQ. Сама по себе очередь не гарантирует доставку — без подтверждений возможна как потеря, так и «зависание» сообщений.
• Неидемпотентные обработчики. При доставке at-least-once дубликаты — норма, а не исключение; без защиты от повторной обработки они превращаются в задвоенные заказы или документы.
• DLQ без владельца и без мониторинга. Сообщения молча накапливаются или устаревают в DLQ, и о проблеме узнают постфактум, когда контрагент уже пожаловался на непришедший документ.
• Раздельная запись бизнес-данных и события об их изменении без outbox-паттерна или аналогичного механизма — источник классической рассинхронизации между базой и внешними системами.
• Остановленное регламентное задание в 1С, которое никто не заметил, потому что нет отдельного алертинга на факт обмена, а не только на ошибку конфигурации.
• Ручные правки настроек обмена «на глаз» без понимания структуры плана обмена — риск повторной загрузки всего периода или потери связи узла.
• Путаница между технической доставкой и юридической значимостью в ЭДО — сообщение может быть технически доставлено, но не иметь предусмотренных сценарием подтверждений, что скажется при налоговой проверке или споре с контрагентом.
• Редкая или пакетная синхронизация остатков при работе с несколькими маркетплейсами одновременно — типовая причина овербукинга и вынужденных отмен заказов.

Как выбрать решение

Если объём обмена небольшой и стабильный, а системы стандартные (например, синхронизация заказов между одним маркетплейсом и типовой учётной системой), обычно достаточно готового коннектора или встроенного механизма 1С — разработка собственной очереди не окупится. Если объём растёт, каналов обмена несколько, требования к скорости реакции высокие (нельзя допустить окно рассинхронизации остатков даже в несколько минут) или обмен связывает разнородные системы за пределами одной платформы — стоит закладывать отдельный брокер сообщений с полным набором механизмов надёжности: подтверждения, идемпотентность, DLQ, при необходимости — outbox.

Ключевые вопросы, на которые стоит ответить до начала проекта: какие типы документов и заказов критичны к потере; допустима ли обработка дубликата и как её избежать; кто и как будет разбирать сообщения, которые не удалось обработать; предусмотрена ли атомарная запись бизнес-данных и события о них там, где это важно.

Как может помочь «Пятый фактор»

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

Как проверить очередь на сбоях, а не только в штатном режиме

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

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

Вывод

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

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

Источники

[1] ru.wikipedia.org — Очередь сообщений — https://ru.wikipedia.org/wiki/Очередь_сообщений

[2] cloud.vk.ru — Очереди сообщений в микросервисной архитектуре: плюсы и минусы технологии — https://cloud.vk.ru/blog/zachem-nuzhny-ocheredi-soobshcheniy-v-mikroservisnoy-arkhitekture/

[3] rabbitmq.com — Consumer Acknowledgements and Publisher Confirms — https://www.rabbitmq.com/docs/confirms

[4] rabbitmq.com — Reliability Guide — https://www.rabbitmq.com/docs/reliability

[5] codelit.io — Dead Letter Queue Patterns: Handling Failed Messages at Scale — https://codelit.io/blog/dead-letter-queue-patterns

[6] glukhov.org — Dead Letter Queues: Handling Poison Messages in Distributed Systems — https://www.glukhov.org/app-architecture/integration-patterns/dead-letter-queues/

[7] developer.confluent.io — The Transactional Outbox Pattern — https://developer.confluent.io/courses/microservices/the-transactional-outbox-pattern/

[8] ubiklab.net — Transactional Outbox. Как не потерять сообщения — https://ubiklab.net/posts/pattern-transactional-outbox/

[9] wiseadvice-it.ru — 1С обмен данными — правила обмена данными между 1С — https://wiseadvice-it.ru/o-kompanii/blog/articles/obmen-dannymi-v-1s/

[10] 1chelp.by — Обмен данными 1С — почему документы не доходят — https://1chelp.by/article/obmen-dannymi-1c-dokumenty-ne-dokhodyat

[11] itcons99.ru — Интеграция 1С:WMS с учётной системой: как настроить обмен данными без потерь — https://itcons99.ru/chasto-zadavaemye-voprosy/stati/integraciya-1s-wms-obmen-dannymi/

[12] astral.ru — Законы об электронном документообороте (ЭДО) в РФ — https://astral.ru/info/elektronnyy-dokumentooborot/zakony-ob-elektronnom-dokumentooborote-rf/

[13] delta-i.ru — Что такое ЭДО и как работает электронный документооборот — https://www.delta-i.ru/print/articles/poleznaya-informacziya/chto-takoe-edo-prostymi-slovami-sistemy-operatory-diadok-i-kak-podklyuchit-elektronnyy-dokumentoobor/

[14] nalog.gov.ru — Обязанности и сервисы операторов электронного документооборота В2В — https://www.nalog.gov.ru/rn77/oedo/duty_b2b/

[15] uniseller.io — Синхронизация остатков на маркетплейсах: как избежать штрафов — https://uniseller.io/blog/sinkhronizaciya-ostatkov-marketpleysy/

[16] moysklad.ru — Интеграция с маркетплейсами: синхронизация статусов заказов — https://www.moysklad.ru/news/integratsiya-s-marketpleysami/

[17] infostart.ru — YandexMQ: простые очереди сообщений в облаке — https://infostart.ru/1c/articles/2529463/

[18] q.diasoft.ru — Шина данных (ESB): что это такое и зачем нужна интеграционная шина в IT-архитектуре — https://q.diasoft.ru/mediacenter/knowledge/shina-dannykh-esb-chto-eto-takoe-i-zachem-nuzhna-integratsionnaya-shina-v-it-arkhitekture/

[19] sb-vnedr.ru — Обмен данными через Enterprise Data и 1С:Шина — https://sb-vnedr.ru/blog/obmen-dannymi-cherez-enterprise-data-i-1c-shina-sobytiynaya-integratsiya-pri-perekhode-na-1c-erp/