Чем отличаются at least once, at most once, exactly once?

Семантика доставки сообщений

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

Три основные гарантии

• At Most Once (максимум один раз): Сообщение отправляется, но если происходит сбой (например, сетевой разрыв или падение потребителя), оно может быть потеряно. Система не пытается повторить отправку. Это самый быстрый, но наименее надёжный подход. Подходит для данных, потеря которых допустима (например, метрики или телеметрия в реальном времени).
• At Least Once (минимум один раз): Система гарантирует доставку, повторяя отправку до получения подтверждения. Это может привести к дублированию сообщений, если подтверждение задержалось, но отправитель уже отправил сообщение повторно. Требует идемпотентной обработки на стороне потребителя. Широко используется в системах очередей, таких как RabbitMQ или Kafka (при определённых настройках).
• Exactly Once (ровно один раз): Идеальная семантика, при которой сообщение обрабатывается потребителем ровно один раз, без потерь и дубликатов. На уровне сети и транспорта в распределённой системе достичь этого крайне сложно из-за теоремы CAP и ненадёжности сетей. На практике реализуется как комбинация: транспортный уровень с гарантией 'at least once' плюс механизмы дедупликации и идемпотентности на уровне бизнес-логики приложения или фреймворка.

Практическое применение и примеры

Рассмотрим пример обработки финансовой транзакции. Использование 'at most once' неприемлемо, так как транзакция может быть потеряна. 'At least once' подходит, но требует проверки, не была ли эта же транзакция уже обработана (идемпотентность). Многие современные потоковые обработчики (Apache Kafka, Apache Flink) декларируют поддержку 'exactly once' для определённых сценариев, но это достигается за счёт координации между производителем, брокером и потребителем, а также ведения транзакционных логов.

// Пример идемпотентного обработчика для семантики 'at least once'
// Используем уникальный ID сообщения для дедупликации
const processedMessageIds = new Set();

function processPayment(message) {
  if (processedMessageIds.has(message.id)) {
    // Сообщение уже обработано, игнорируем дубликат
    console.log('Duplicate message ignored:', message.id);
    return;
  }
  // Бизнес-логика: списание средств
  deductFromAccount(message.accountId, message.amount);
  // Сохраняем ID обработанного сообщения
  processedMessageIds.add(message.id);
  console.log('Payment processed:', message.id);
}

// Примечание: в реальности Set сбрасывается при перезапуске,
// поэтому ID нужно хранить в постоянном хранилище (БД, Redis).

Вывод: Выбор семантики зависит от требований к данным и допустимых компромиссов. Для критически важных данных без потерь (платежи, заказы) используйте комбинацию 'at least once' с идемпотентной обработкой, что на практике даёт 'exactly once' на уровне бизнес-логики. Для данных, где важнее скорость, а потеря части записей допустима (логи, сенсорные данные), может подойти 'at most once'.