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

Question

Подтверждение управляется выбором режима: авто-ack или ручной ack (basic_ack). Повторная доставка зависит от basic_nack/basic_reject и флага requeue, а также от падения канала (все unacked вернутся в очередь). Количество одновременно выданных сообщений регулируется basic_qos(prefetch_count=...). Для “плохих” сообщений используют DLX/DLQ, чтобы они уходили в отдельную очередь вместо бесконечных повторов. Для ретраев применяют TTL и dead-letter маршрутизацию или отложенную доставку через отдельные механизмы.

YeaHub · Accepted Answer

Управление подтверждением и повторной доставкой делится на настройки потребителя и параметры очереди/политики.1) Настройки на стороне consumer (ключевые)Режим подтвержденияauto-ack: сообщение считается обработанным сразу при доставке (риск потерь при падении воркера)manual ack: явный basic_ack после обработкиnack/reject и requeuebasic_nack(..., requeue=True) вернет сообщение в очередь для повторной обработкиrequeue=False обычно отправит сообщение в DLQ (если настроен DLX), иначе сообщение может быть отброшено (зависит от конфигурации)QoS / Prefetchbasic_qos(prefetch_count=N) ограничивает число unacked на канале/потребителеchannel.basic_qos(prefetch_count=50)
channel.basic_consume(queue="tasks", on_message_callback=on_message, auto_ack=False)
2) Настройки очереди и политики (queue arguments)Здесь важна логика: очередь сама по себе не “включает ack”, но задает правила, куда идут сообщения при отказах и как долго живут.Dead Letter Exchange (DLX)аргументы очереди: x-dead-letter-exchange, x-dead-letter-routing-keyиспользуются, чтобы “отбитые”/просроченные сообщения уходили в DLQTTLx-message-ttl (время жизни сообщений в очереди)x-expires (время жизни самой очереди)вместе с DLX TTL часто используется для retry-очередей: сообщение “ждет” TTL, затем улетает обратно в основную очередь через DLXОграничение длины очередиx-max-length, x-max-length-bytesпри переполнении сообщения могут “выталкиваться” (обычно в DLX при правильной настройке), что влияет на гарантию “не потерять”3) Как проектируют повторную доставку без бесконечного циклаRetry через отдельные очередиmain -> retry(с TTL) -> mainпосле N попыток отправлять в DLQ для ручного разбораСчетчик попытокхранить счетчик в заголовках/метаданных или во внешнем хранилищепосле превышения лимита: requeue=False и маршрутизация в DLQВыводНа практике управление подтверждением и повторной доставкой строят вокруг manual ack, nack/requeue, prefetch, а для “плохих” сообщений добавляют DLX/DLQ и retry-схемы через TTL или отдельные очереди.