At-least-once vs At-most-once vs Exactly-once delivery?

#Где теряются и дублируются сообщения

Каждый участок нужно настроить: подтверждения публикации (publisher confirms / acks=all), устойчивое хранение (durable очереди, persistent сообщения, репликация), момент подтверждения потребителем.

#At-most-once

// RabbitMQ: autoAck = true — брокер считает сообщение доставленным при отправке
await channel.BasicConsumeAsync("metrics", autoAck: true, consumer);

Уместно: телеметрия, метрики, некритичные уведомления, где потеря дешевле дубля или сложности.

#At-least-once

await channel.BasicQosAsync(prefetchSize: 0, prefetchCount: 20, global: false);
consumer.ReceivedAsync += async (_, ea) =>
{
    try
    {
        await HandleAsync(ea.Body, ea.BasicProperties.MessageId);
        await channel.BasicAckAsync(ea.DeliveryTag, multiple: false);          // ПОСЛЕ обработки
    }
    catch (Exception)
    {
        await channel.BasicNackAsync(ea.DeliveryTag, false, requeue: false);   // → DLX после исчерпания ретраев
    }
};
await channel.BasicConsumeAsync("payments", autoAck: false, consumer);

Источники дублей: падение потребителя после обработки до ack, таймаут подтверждения, ребалансировка партиций в Kafka, повторная публикация продюсером (не получил подтверждение, хотя брокер записал), outbox relay после сбоя.

#Exactly-once: почему «доставки» не бывает

Отправитель не может отличить «сообщение потерялось» от «потерялось подтверждение» (проблема двух генералов). Поэтому он либо повторяет (дубли → at-least-once), либо нет (потери → at-most-once).

Что реально достижимо — exactly-once processing (effectively-once):

public async Task HandleAsync(PaymentRequested msg, Guid messageId, CancellationToken ct)
{
    await using var tx = await db.Database.BeginTransactionAsync(ct);
    var isNew = await db.Database.ExecuteSqlAsync(
        $"INSERT INTO inbox (message_id, consumer) VALUES ({messageId}, 'payments') ON CONFLICT DO NOTHING", ct) == 1;
    if (isNew)
    {
        db.Payments.Add(Payment.For(msg.OrderId, msg.Amount));
        await db.SaveChangesAsync(ct);
    }
    await tx.CommitAsync(ct);
}

#Kafka: exactly-once semantics

• Идемпотентный продюсер (enable.idempotence = true): брокер отбрасывает дубли повторных отправок (по producer id + sequence number).
• Транзакции Kafka: чтение из топика, запись в выходной топик и коммит offset — атомарно (read-process-write). Работает, пока все эффекты внутри Kafka (Kafka Streams).
• Как только эффект выходит за пределы Kafka (запись в PostgreSQL, вызов платёжного API) — снова нужна идемпотентность на стороне эффекта.

#Сравнение

#Производитель тоже важен

var channel = await connection.CreateChannelAsync(new CreateChannelOptions(publisherConfirmationsEnabled: true, publisherConfirmationTrackingEnabled: true));
await channel.BasicPublishAsync("events", "order.placed", mandatory: true, props, body);   // бросит исключение, если брокер не подтвердил

acks=all                      # подтверждение от всех in-sync реплик
enable.idempotence=true       # без дублей при повторной отправке
min.insync.replicas=2         # на стороне топика

И конечно — Outbox: без него сообщение может потеряться ещё до брокера (сбой между коммитом БД и публикацией).

#Вопросы на засыпку

#Итог

At-most-once теряет, at-least-once дублирует, а exactly-once как доставка невозможен — возможен только эффект ровно одного раза: надёжная доставка (outbox, подтверждения, durable-хранение) плюс идемпотентная обработка (Inbox, upsert, ключи идемпотентности). Это стандартный рецепт для любых важных бизнес-сообщений.