Какие уровни гарантий доставки сообщений существуют (at-most-once, at-least-once, exactly-once) и как на практике приблизиться к семантике exactly-once?

Question

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

YeaHub · Accepted Answer

Гарантии доставки сообщений и достижение “практически exactly-once”В системах очередей важно понимать, как часто сообщение будет обработано.1. Уровни доставки1. At-most-onceОпределение: сообщение может быть доставлено 0 или 1 раз.без подтвержденийбез повторных попытоквысокая скоростьмогут быть потериИспользуется там, где потеря не критична.2. At-least-onceОпределение: сообщение будет доставлено хотя бы один раз, но возможны дубли.Это стандартная модель RabbitMQ:сообщения подтверждаются вручнуюпри ошибке → переотправляютсявозможны дубликаты при авариях3. Exactly-onceОпределение: каждое сообщение доставлено и обработано ровно один раз.Почти недостижимо в распределённых системах из-за:сбоев сетиповторной доставкиперезапуска воркеровтранзакционных коллизиймножественных точек отказа2. Как приблизиться к exactly-once на практике1. Идемпотентность обработчиковОпределение: идемпотентность — операция, которая при повторном выполнении не меняет результат.Пример:вместо balance += 100 → задаём новое значение на основе событиявместо создания записи → UPSERTоперации не должны зависеть от того, выполнялись ли они ранее2. Дедупликация сообщенийСохраняем идентификатор сообщения:таблица processed_messagesRedis-сет с TTLхеш события (event id)Алгоритм:сообщение приходитпроверяем, существует ли ID в историиесли да → пропускаемесли нет → обрабатываем и записываем3. Транзакции на уровне базыОбъединяем:запись результатазапись processed IDв одну транзакцию:phpBEGIN;

if exists(processed_id = :id) then rollback; end;

update balance set amount = amount + :delta;
insert processed_id values (:id);

COMMIT;
Это делает обработку атомарной.4. Atomic ackПроблема:если вы ack-ните сообщение до коммита → можно потерять данныеесли ack после — возможен дубликатРешение:ack → строго после успешного коммитаack и commit должны быть настолько близки, насколько возможно5. Outbox pattern (похож на Event Sourcing)запись события в outbox таблицуфиксация транзакцииворкер выгружает события из outbox и отправляетдедупликация на стороне потребителя6. Single consumer per entity streamГарантирует порядок и упрощает идемпотентность.3. Комбинация, приближающая exactly-onceНа практике используется:идемпотентностьхранение обработанных IDsатомарные транзакцииack после commitпо возможности — один поток обработки на сущностьЭто даёт “практически exactly-once” — то есть гарантирует отсутствие ошибок даже при ретраях и дубликатах.4. ВыводExactly-once трудно достижим, но на практике его моделируют за счёт идемпотентности, дедупликации и транзакций. At-least-once остаётся базовым механизмом RabbitMQ, а разработчик заботится о корректности на уровне бизнес-логики.