Dead Letter Queue и Dead Letter Exchange (проблемное отделение почты)

Это соседи по одной цепочке: не выбор «или — или», а две части одного механизма обработки сломанных сообщений. Exchange решает, куда направить, Queue держит у себя и ждёт, пока разберутся.

На пальцах

Представь обычное почтовое отделение. Письма приходят, сортируются по адресу и уходят по маршрутам. Но иногда что-то идёт не так: адресат съехал, отказался принять, письмо слишком долго лежало без ответа. Выбрасывать такие письма почта не хочет — за них могут спросить, да и потерять жалко. Поэтому есть отдельная процедура: проблемное письмо отправляется в специальное «отделение проблемной почты». Туда ведёт маршрут через особую сортировочную станцию — это exchange. На станции письмо раскладывается по нужным ячейкам и попадает в специальный почтовый ящик-холодильник, где копится до разбора — это queue. Без такой связки любое «сломанное» письмо либо теряется, либо засоряет собой основные ящики: курьер не знает, что с ним делать, и кладёт обратно в общую стопку.

Что делает каждый

Dead Letter Exchange — это обычный exchange (чаще всего fanout или direct), на который RabbitMQ переиздаёт сообщение, когда оно «умерло»: его отвергли с requeue=false, истёк TTL (время жизни) или очередь переполнена. Exchange сам по себе ничего не хранит — только маршрутизирует по ключу: «такое сообщение — туда». Указывается в аргументах очереди через x-dead-letter-exchange.

Dead Letter Queue — обычная очередь без специального типа. Её единственная особенность — она принимает сообщения из DLX и держит их у себя, пока кто-то не разберёт: прочитает лог, поправит обработчик и вернёт сообщение в работу, или удалит совсем.

В чём разница

Что из этого следует

Без DLX сообщение, которое не смогли обработать, либо теряется, либо возвращается в основную очередь и засоряет её бесконечными повторами. Без DLQ — негде скопить «мёртвые» сообщения, и DLX отправляет их в пустоту. Поэтому нужны обе части: DLX задаётся как аргумент рабочей очереди, DLQ — обычная очередь с привязкой на этот exchange. Например, у интернет-магазина очередь заказов падает с ошибкой при списании оплаты — без связки DLX/DLQ ты теряешь заказ молча; с ними он лежит в отдельной очереди, ты его видишь, чинишь и возвращаешь в работу.

Как устроено

Шаги, когда сообщение «умирает» в RabbitMQ:

1. Сообщение приходит в рабочую очередь (например, orders.processing). У неё при создании указан аргумент x-dead-letter-exchange = orders.dlx. Опционально — x-dead-letter-routing-key, если хочется переписать ключ маршрутизации под нужный binding.
2. В одном из трёх случаев сообщение считается «мёртвым»:
   • потребитель сделал basic.reject или basic.nack с флагом requeue=false;
   • истёк per-message TTL (свойство expiration в сообщении) или TTL самой очереди (x-message-ttl);
   • очередь переполнена (x-max-length по числу сообщений или x-max-length-bytes по объёму).
3. RabbitMQ не удаляет сообщение и не возвращает в начало. Вместо этого он публикует его в exchange, указанный в x-dead-letter-exchange — это и есть DLX.
4. DLX работает по обычным правилам маршрутизации: смотрит на routing key (исходный или переписанный через аргумент) и кладёт сообщение во все очереди, на которые у него есть binding. Один binding — сообщение попадёт в одну очередь; fanout с несколькими binding'ами — разойдётся по нескольким (например, в очередь для логов и в очередь для переотправки).
5. RabbitMQ дописывает в сообщение заголовок x-death — массив записей, где указаны исходные exchange и queue, причина смерти (rejected / expired / maxlen), время и количество попыток. Эти заголовки читает тот, кто разгребает DLQ.
6. Сообщение лежит в DLQ, пока его не заберёт специальный потребитель — обычно скрипт разбора, который смотрит логи, чинит данные и отправляет сообщение заново в основную очередь через её рабочий exchange.

Здесь аналогия хромает на одном: в почте «проблемное отделение» — это одно здание, а в RabbitMQ DLX и DLQ — два разных объекта, общающихся через binding. Если помнить это, цепочка «сломалось → exchange → queue → разбор» складывается правильно.