Перейти на PRO

Что такое Dead Letter Queue (DLQ) и для чего она используется?

Тип вопроса: Брокеры сообщений Вероятность: 22% Категория: Golang Разработчик

Ответ

Dead Letter Queue (DLQ) — это специальная очередь в системах обмена сообщениями (например, RabbitMQ, Kafka), предназначенная для хранения сообщений, которые не могут быть успешно обработаны основной очередью.

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

Основные причины попадания сообщения в DLQ:

  1. Ошибка обработки: Обработчик (consumer) явно отклоняет сообщение (например, с помощью NACK в RabbitMQ), потому что не может его обработать (например, из-за неверного формата данных или временной недоступности внешнего сервиса).
  2. Истечение TTL (Time-To-Live): Сообщение находилось в очереди дольше установленного времени жизни.
  3. Превышение длины очереди: Основная очередь достигла максимального количества сообщений.

Как это работает (на примере RabbitMQ):

  1. Создается основная очередь (work-queue) и настраивается так, чтобы при невозможности обработки она перенаправляла сообщения в специальный обменник (dlx-exchange).
  2. Создается очередь для «мертвых» писем (dlq-queue).
  3. dlq-queue привязывается к dlx-exchange.

Пример обработчика на Go, который может отправить сообщение в DLQ:

// ... код подключения к RabbitMQ ...

msgs, err := ch.Consume(
    "work-queue", // Название основной очереди
    "",           // consumer
    false,        // auto-ack = false, ручное подтверждение
    false,
    false,
    false,
    nil,
)

for msg := range msgs {
    log.Printf("Получено сообщение: %s", msg.Body)

    // Пытаемся обработать сообщение
    if err := processMessage(msg.Body); err != nil {
        log.Printf("Ошибка обработки: %v. Отправляем в DLQ.", err)
        // Отклоняем сообщение (requeue=false), чтобы оно ушло в DLQ,
        // а не вернулось в исходную очередь.
        msg.Nack(false, false)
    } else {
        // Сообщение успешно обработано
        msg.Ack(false)
    }
}

Ответ 18+ 🔞

А, слушай, смотри, сейчас про такую штуку расскажу, которая в любой нормальной системе обязана быть, а то потом охуевать будешь, когда всё посыпется. Dead Letter Queue, или просто DLQ — это типа карантин для сообщений, которые твоя система переварить не смогла. Представь: у тебя RabbitMQ или Kafka, там очередь сообщений, всё летит, как по маслу, и тут — бац! — какое-то сообщение прилетело кривое, с ошибкой, или сервис-обработчик на тот момент был в отключке. Так вот, чтобы эта одна ерунда не застопорила всю очередь и не пошла по кругу как последний идиот, её аккуратно выпинывают в отдельную, специальную очередь. Туда, где она никому не мешает и лежит, пока ты, разработчик, не придёшь, не посмотришь и не решишь: то ли исправить и запихнуть обратно, то ли нахуй удалить.

Зачем это вообще нужно, спросишь? Да чтобы не терять данные, ёпта! И чтобы одна сломанная хуйня не блокировала всю работу. Типа изоляция проблемных элементов, как в инфекционном отделении.

Почему сообщение может туда угодить? Причин несколько, но основные вот:

  1. Обработчик обосрался. Ну, то есть, consumer явно говорит: «Бля, не могу это обработать, валидация не прошла, или внешний сервис лег». И отправляет сообщение в игнор с флагом «не пытаться снова».
  2. Сообщение протухло. У каждого сообщения может быть срок годности (TTL). Если его за это время не обработали — привет, DLQ.
  3. Очередь переполнилась. Лимит на размер очереди достигнут, новые сообщения не лезут — старые и неудачные летят в DLQ.

Как это выглядит в жизни (на примере RabbitMQ)?

  1. Создаёшь основную рабочую очередь (work-queue). Говоришь ей: «Слушай, если сообщение не прокатит — отправляй его в обменник для лузеров (dlx-exchange)».
  2. Создаёшь саму DLQ (dlq-queue).
  3. Привязываешь эту DLQ к тому самому обменнику для лузеров. Всё, схема готова. Проблемное сообщение летит из основной очереди в обменник, а оттуда — прямиком в карантин.

Вот тебе кусочек кода на Go, как это может выглядеть в обработчике:

// ... тут подключение к RabbitMQ, опустим для ясности ...

msgs, err := ch.Consume(
    "work-queue", // Основная очередь, где работа кипит
    "",           // consumer
    false,        // auto-ack = false! Руками будем подтверждать
    false,
    false,
    false,
    nil,
)

// Бесконечный цикл на приём сообщений
for msg := range msgs {
    log.Printf("Получил сообщение: %s", msg.Body)

    // Пробуем его обработать
    if err := processMessage(msg.Body); err != nil {
        // Ой, всё! Не вышло.
        log.Printf("Обосрался при обработке: %v. Выпинываю в DLQ.", err)
        // Отказываемся от сообщения (Nack) и НЕ просим перекинуть обратно (requeue=false).
        // Оно улетит в DLQ, как и договаривались.
        msg.Nack(false, false)
    } else {
        // Всё чики-пуки, сообщение обработано
        msg.Ack(false)
    }
}

Вот и вся магия. Без DLQ — это как ходить по тонкому льду, один неверный шаг и пипец всему потоку. А с ней — есть шанс всё починить, не теряя ни хуя.

© ХакСобесов, 2026
support@hacksobesov.com