Dead-letter queue (DLQ) — это отдельная очередь для заданий, которые обработчик не смог завершить после допустимых попыток. Если она растёт, не отправляйте всё обратно одним нажатием: сначала остановите причину, затем разделите сообщения по типу сбоя и возвращайте их небольшими контролируемыми партиями.
Безопасный порядок такой: зафиксировать состояние очереди, проверить срок хранения и требования к порядку, выбрать один класс ошибок, обеспечить идемпотентность обработки и выполнить пробный повтор. Лишь после проверки результата стоит разбирать остальной объём.
Почему нельзя просто вернуть все задания
DLQ сохраняет не мусор, а следы сбоя. Сообщение могло попасть туда из-за временной недоступности зависимости, превышения числа попыток, истечения срока, неверного формата или бизнес-конфликта. Точная причина и служебные атрибуты зависят от брокера.
Массовый повтор до исправления причины создаст ту же ошибку снова и добавит нагрузку. Ещё опаснее частично выполненная задача: повтор может второй раз списать деньги, отправить письмо, изменить остаток или создать дубликат записи.
Что зафиксировать до любых действий
- Остановите автоматический redrive, если он уже включён, но не удаляйте сообщения.
- Сохраните число сообщений, возраст самого старого, исходную очередь, причину переноса и количество попыток.
- Возьмите несколько безопасно просмотренных примеров и выпишите идентификатор сообщения, тип события, время, версию схемы и correlation ID. Не копируйте в рабочий журнал персональные данные и секреты.
- Проверьте срок хранения DLQ: диагностика должна закончиться раньше, чем брокер удалит старые сообщения.
- Запишите версию обработчика и изменения, после которых начался рост очереди.
Если идентификатор проходит через прокси, приложение и фонового обработчика, используйте единый маршрут поиска. Подробный порядок есть в статье как связать запрос с логами прокси и приложения.
Разделите сообщения по причине
Не смешивайте разные сбои в одной повторной отправке.
Временная недоступность
Тайм-аут базы, ответ внешнего API или краткий сетевой сбой могут исчезнуть после восстановления зависимости. Перед повтором подтвердите, что зависимость отвечает стабильно, а лимиты и тайм-ауты обработчика не создадут новый каскад.
Ошибка данных или схемы
Неизвестное поле, обязательное пустое значение и старая версия события сами не исправятся. Нужен совместимый обработчик, контролируемое преобразование или отдельное решение об отклонении. Не редактируйте payload вручную без журнала изменений: после этого трудно доказать, что именно было обработано.
Бизнес-конфликт
Заказ уже отменён, запись удалена или операция выполнена ранее. Здесь повтор может быть неверным даже при технически исправном сообщении. Обработчик должен сверить текущее состояние и завершить задачу без повторного побочного эффекта.
«Ядовитое» сообщение
Если один и тот же payload стабильно ломает обработчик, изолируйте его. Увеличение числа попыток только маскирует дефект и расходует ресурсы.
Как подготовить безопасный повтор
1. Исправьте первопричину
Сначала разверните и проверьте исправление: совместимость схемы, доступ к зависимости, тайм-аут, лимит или бизнес-правило. Новый код должен корректно обрабатывать и старое сообщение, если именно оно осталось в DLQ.
2. Проверьте идемпотентность
Одна операция должна приводить систему к одному результату даже при повторной доставке. Для этого обычно сохраняют стабильный идентификатор операции, проверяют уже выполненное действие и фиксируют результат атомарно.
Если задача вызывает API, полезно отдельно проверить сценарий, описанный в материале как повторить API-запрос после тайм-аута без дублей. Новый идентификатор сообщения не должен превращать старую бизнес-операцию в новую.
3. Учитывайте порядок и зависимости
В очередях с гарантией порядка выборочный повтор может нарушить последовательность событий. Проверьте ключ группировки, зависимые сообщения и то, не ждёт ли позднее событие результата раннего. Иногда безопаснее воспроизвести целую связанную последовательность, а не один элемент.
4. Запустите пробную партию
Выберите один однородный класс ошибки и малую партию. Сохраните исходные идентификаторы и correlation ID, ограничьте скорость и заранее задайте условия остановки: повторная ошибка, неожиданный побочный эффект, рост задержки или нагрузки.
После запуска проверьте не только факт исчезновения сообщений из DLQ. Убедитесь, что появились ожидаемые записи или статусы, не возникли дубли, а задания не вернулись в очередь ошибок.
5. Расширяйте объём постепенно
Если пробная партия прошла чисто, увеличивайте объём ступенчато. Между этапами сверяйте число успешных обработок, повторных отказов, глубину основной очереди, возраст старейшего сообщения, нагрузку на базу и внешние зависимости.
Когда разбор можно считать завершённым
Очередь стала пустой — недостаточный критерий. Нужны одновременно четыре результата:
- первопричина исправлена и описана;
- каждое сообщение либо успешно обработано, либо получило явное решение об отклонении;
- побочные эффекты и дубли проверены;
- для повторения сбоя есть сигнал мониторинга и понятный ответственный.
Не отключайте DLQ после инцидента. Настройте оповещение о появлении новых сообщений, росте их числа и возрасте самого старого, а также отдельный сигнал о повторном отказе после redrive.
Web-Puls не видит внутреннюю очередь и не заменяет метрики брокера. Внешний мониторинг критичного публичного URL или API дополняет их: он показывает, не повлиял ли сбой фоновой обработки на доступность и время ответа для пользователя.
Вывод
Разбирайте DLQ как инцидент, а не как папку для очистки: сохраните доказательства, устраните причину, обеспечьте идемпотентность и повторяйте обработку небольшими проверяемыми партиями. Если очередь связана с недоступностью сайта или API и нужен разбор серверной части, оставьте заявку на профессиональную поддержку.