Exactly-once semantics: миф или реальность в распределённых системах

"Exactly-once delivery" звучит как святой Грааль распределённых систем. Сообщение обрабатывается ровно один раз — не теряется и не дублируется. Казалось бы, идеально. Но возможно ли это на самом деле?

Разберёмся, где маркетинг, а где инженерная реальность.

Три модели доставки сообщений

В распределённых системах обычно говорят о трёх гарантиях доставки:

1. At-most-once

Сообщение доставляется не более одного раза.

• Может потеряться.
• Дубликатов нет.
• Минимальные накладные расходы.

Подходит там, где потеря допустима (например, метрики).

2. At-least-once

Сообщение будет доставлено хотя бы один раз.

• Потерь нет.
• Возможны дубликаты.
• Требуется идемпотентность обработки.

Самая распространённая модель в брокерах сообщений.

3. Exactly-once

Сообщение доставляется и обрабатывается ровно один раз.

• Без потерь.
• Без дублей.
• Максимальная сложность реализации.

Звучит красиво. Но дьявол в деталях.

Почему exactly-once — сложная задача

В распределённой системе всегда возможны:

• сетевые таймауты;
• повторные отправки;
• падение продюсера;
• падение консьюмера;
• падение брокера;
• split-brain сценарии.

Если продюсер не получил подтверждение, он повторит отправку. Если консьюмер не успел зафиксировать offset — сообщение будет обработано снова.

На уровне сети невозможно отличить:

• "сообщение не доставлено"
• от "сообщение доставлено, но ACK потерян"

А значит, без дополнительных механизмов дубликаты неизбежны.

Фундамент: идемпотентность, а не магия доставки

Самый надёжный и практичный способ приблизиться к exactly-once — идемпотентная обработка.

Идея простая:

пусть сообщение может прийти несколько раз,
но эффект от его обработки будет только один.

Именно этот подход используется в реальных production-системах, а не абстрактные «гарантии доставки».

Базовые принципы идемпотентности, источники дубликатов и использование idempotency key на уровне API подробно разобраны в отдельной статье — это логичная отправная точка перед разговором о распределённых гарантиях обработки.

Важное различие: delivery vs processing

Часто под exactly-once понимают разные вещи:

1. Exactly-once delivery — сообщение физически доставлено один раз.
2. Exactly-once processing — бизнес-операция выполнена один раз.

Первое почти недостижимо в чистом виде.
Второе — возможно, но только с дополнительной логикой.

И именно processing важнее для бизнеса.

Как достигают "почти" exactly-once

1. Идемпотентность

Самый надёжный способ — сделать обработку идемпотентной.

Пример:

• У каждого события есть уникальный ID.
• Перед выполнением операции проверяется, был ли этот ID уже обработан.
• Если был — операция пропускается.

Это переносит гарантию из транспорта в бизнес-логику.

2. Транзакции

Некоторые системы поддерживают транзакционные механизмы:

• запись сообщения
• фиксация offset
• обновление состояния

в рамках одной атомарной операции.

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

3. Outbox pattern

Популярный паттерн:

1. Бизнес-операция и запись события происходят в одной транзакции БД.
2. Отдельный процесс публикует события из таблицы outbox.

Так исключается ситуация, когда данные изменились, а событие не отправилось (или наоборот).

Теоретическое ограничение

CAP-теорема напоминает: в распределённой системе невозможно одновременно гарантировать:

• согласованность
• доступность
• устойчивость к сетевым разделениям

Exactly-once в строгом смысле требует глобальной координации и консенсуса, что увеличивает latency и снижает доступность.

В реальных production-системах это почти всегда компромисс.

Где exactly-once реально нужно

Есть классы задач, где дубликаты критичны:

• финансовые транзакции
• списания средств
• биллинг
• инвентаризация

Но даже там чаще применяют:

• уникальные transaction_id
• дедупликацию на уровне БД
• строгие бизнес-ограничения

То есть проблему решают выше уровня брокера.

Где достаточно at-least-once

Во многих системах дубликаты не страшны:

• логирование
• аналитика
• построение отчётов
• кэширование

В таких случаях сложность exactly-once не оправдана.

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

В индустрии "exactly-once" почти всегда означает:

"Exactly-once within a defined boundary and under certain assumptions."

Например:

• внутри одного кластера
• при использовании транзакций
• при отсутствии catastrophic failure

Это не магия. Это инженерная договорённость.

Главный вывод

Exactly-once как абсолютная гарантия в распределённой системе — скорее теоретическая модель.

Но exactly-once processing — вполне достижимая цель, если:

• делать операции идемпотентными;
• использовать транзакционные механизмы;
• применять outbox-паттерн;
• проектировать систему с учётом повторной доставки.

Поэтому правильный вопрос звучит не так:

"Поддерживает ли система exactly-once?"

А так:

"Где именно обеспечивается идемпотентность и на каком уровне происходит дедупликация?"

Именно там и находится настоящая гарантия.