Какие механизмы позволяют гарантировать, что сообщение не потеряется при падении воркера?

Надежность “сообщение не потеряется” достигается комбинацией механизмов на разных этапах: публикация, хранение, доставка, обработка.

1) Защита от падения воркера (consumer-side)

1. Ручные подтверждения (manual ack)

• сообщение считается обработанным только после basic_ack.

• при падении до ack оно вернется в очередь и будет переотправлено.

2. prefetch (QoS)

• ограничивает количество сообщений, одновременно выданных воркеру.

• уменьшает объем “недообработанного” при падении.

2) Защита от потерь при падении брокера (broker-side)

1. Устойчивая очередь (durable queue)

• очередь переживает рестарт брокера (в терминах метаданных).

2. Персистентные сообщения (persistent messages)

• сообщение помечается для записи на диск.

• важно: это не абсолютная гарантия без правильной конфигурации и подтверждений от брокера.

3. Репликация очереди

• quorum queue (репликация через Raft) обычно дает более предсказуемую устойчивость при падениях узлов кластера.

3) Защита на этапе публикации (producer-side)

1. Publisher confirms

• продюсер получает подтверждение от брокера, что публикация принята.

• при отсутствии confirm продюсер может повторить отправку (отсюда снова нужна идемпотентность).

2. Обработка возвратов (mandatory + return)

• если сообщение не может быть маршрутизировано, продюсер узнает об этом и не “теряет” его молча.

4) Работа с “плохими” сообщениями без потери

1. Dead Letter Exchange / Dead Letter Queue (DLX/DLQ)

• сообщения, которые нельзя обработать, уходят в отдельную очередь для анализа/ретраев.

2. Retry-стратегия

• повторные попытки через отдельные очереди с TTL (отложенная повторная доставка), либо через delayed message plugin (если используется).

Пример: публикация с confirm (pika, концептуально)

channel.confirm_delivery()  # включить publisher confirms

ok = channel.basic_publish(
    exchange="",
    routing_key="tasks",
    body=b"...",
    properties=pika.BasicProperties(delivery_mode=2),  # persistent
)
if not ok:
    # повторить публикацию / записать в outbox
    handle_publish_failure()

Вывод
Чтобы “не терять” сообщения, обычно комбинируют: manual ack у консюмера, durable + persistent у брокера, publisher confirms у продюсера и DLQ/retry для нештатных кейсов.