Использовал ли retry и dead letter queue для обработки ошибок в RabbitMQ

Что проверяют

Был ли у вас реальный опыт с падающими сообщениями и понимаете ли вы механику RabbitMQ: когда сообщение уходит в dead letter и как сделать паузу между попытками. Следом обычно просят нарисовать схему очередей или спрашивают, что делать с тем, что скопилось в DLQ.

Как отвечать

Опирайтесь на свой проект: какой был поток, какие ошибки считались временными, сколько попыток и с какими интервалами. Цифры должны быть вашими. Технический каркас:

• dead letter exchange: у очереди задаётся x-dead-letter-exchange, лучше через policy, чтобы менять без пересоздания очереди. Сообщение уходит туда при basic.reject или basic.nack с requeue=False, по истечении TTL, при переполнении по x-max-length, а у quorum-очередей ещё и при превышении x-delivery-limit;
• задержка ретраев: встроенного отложенного повтора нет. Классическая схема: при ошибке сообщение уходит в очередь ожидания с x-message-ttl, чей dead letter exchange ведёт обратно в рабочую. Для экспоненциальной задержки заводят несколько таких очередей, например на 10 секунд, минуту и 10 минут. Номер попытки берут из заголовка x-death или своего;
• финал: после исчерпания попыток сообщение уходит в DLQ, на её размер ставят алерт, а переотправку делают скриптом после исправления;
• Python: в pika и aio-pika это ручные ack и nack. В Celery есть autoretry_for, retry_backoff и acks_late, но повтор там идёт новой публикацией задачи, а не через DLX.

Если такого опыта не было, скажите честно и опишите, как построили бы схему, сославшись на похожее: ретраи в Celery, retry-топики в Kafka.

Где спотыкаются

Делают nack с requeue=True на любую ошибку. В классической очереди ядовитое сообщение возвращается на своё место и крутится по кругу на полной скорости, забивая консьюмер и логи.

Делают ретрай через time.sleep в обработчике. Консьюмер простаивает, prefetch занят, а блокирующее соединение pika не отправляет heartbeat, и брокер его закрывает.

Забывают, что доставка «хотя бы один раз» вместе с ретраями даёт дубли. Без идемпотентной обработки повтор отправит письмо дважды или создаст второй заказ.