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

Question

Короткий ответ (3–6 предложений)Чтобы сообщение не потерялось при падении воркера, используют ручные подтверждения (ack) и подтверждают сообщение только после успешной обработки. Чтобы не потерять сообщение при падении брокера, делают очередь “устойчивой” (durable) и публикуют сообщения как persistent. Для надежной публикации применяют publisher confirms, чтобы продюсер знал, что брокер принял сообщение. Для отказоустойчивости очереди используют репликацию (например, quorum queues). Для проблемных сообщений добавляют DLQ и retry-механизмы.

YeaHub · Accepted Answer

Надежность “сообщение не потеряется” достигается комбинацией механизмов на разных этапах: публикация, хранение, доставка, обработка.1) Защита от падения воркера (consumer-side)Ручные подтверждения (manual ack)сообщение считается обработанным только после basic_ack.при падении до ack оно вернется в очередь и будет переотправлено.prefetch (QoS)ограничивает количество сообщений, одновременно выданных воркеру.уменьшает объем “недообработанного” при падении.2) Защита от потерь при падении брокера (broker-side)Устойчивая очередь (durable queue)очередь переживает рестарт брокера (в терминах метаданных).Персистентные сообщения (persistent messages)сообщение помечается для записи на диск.важно: это не абсолютная гарантия без правильной конфигурации и подтверждений от брокера.Репликация очередиquorum queue (репликация через Raft) обычно дает более предсказуемую устойчивость при падениях узлов кластера.3) Защита на этапе публикации (producer-side)Publisher confirmsпродюсер получает подтверждение от брокера, что публикация принята.при отсутствии confirm продюсер может повторить отправку (отсюда снова нужна идемпотентность).Обработка возвратов (mandatory + return)если сообщение не может быть маршрутизировано, продюсер узнает об этом и не “теряет” его молча.4) Работа с “плохими” сообщениями без потериDead Letter Exchange / Dead Letter Queue (DLX/DLQ)сообщения, которые нельзя обработать, уходят в отдельную очередь для анализа/ретраев.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 для нештатных кейсов.