Сообщение из очереди не удаётся обработать после нескольких повторных попыток. Какой механизм изолирует его, чтобы не блокировать остальные сообщения?
Для этого используют очередь недоставленных сообщений, или Dead Letter Queue (DLQ). После исчерпания заданного числа попыток сообщение перемещается из основной очереди в DLQ, поэтому проблемное сообщение не удерживает обработку остальных. DLQ должна поддерживаться процессом анализа, исправления причины сбоя и контролируемого повторного запуска.
В асинхронных интеграциях повторная доставка обычно нужна для временных сбоев: недоступности сервиса, сетевой ошибки или кратковременной перегрузки. Однако некоторые сообщения являются постоянно неисправимыми: они нарушают схему, содержат некорректные данные или вызывают ошибку в бизнес-правилах.
Без отдельного механизма такие сообщения либо бесконечно повторяются, либо блокируют очередь. DLQ появилась как практический способ отделить временные ошибки от сообщений, требующих ручного или специального разбора.
Если сообщение всегда ставится в начало очереди после неудачной обработки, потребитель может снова и снова получать его первым. При последовательной обработке это задерживает или полностью останавливает корректные сообщения, создавая эффект poison message — сообщения, отравляющего очередь.
Бесконечные повторы также создают лишнюю нагрузку на потребителя и зависимые системы. Простое удаление сообщения быстрее восстанавливает поток, но приводит к потере данных и невозможности установить, что именно не обработалось.
Потребитель обрабатывает сообщение и при ошибке подтверждает неуспешную попытку по правилам брокера или интеграционного слоя. Сообщение получает ограниченное число повторов, обычно с задержкой и, при необходимости, увеличивающимся интервалом. После последней неудачи оно перемещается в DLQ вместе с исходным содержимым и диагностическими метаданными.
В DLQ важно сохранять идентификатор сообщения, время поступления, число попыток, причину последней ошибки, сведения о маршруте и версию схемы. Эти данные позволяют отличить ошибку данных от сбоя потребителя и понять, можно ли безопасно повторить обработку.
Повторная обработка из DLQ должна быть управляемой: после исправления причины оператор или отдельный процесс возвращает сообщения в основную очередь либо запускает их через специальный маршрут. Такой запуск должен учитывать идемпотентность, потому что сообщение могло фактически обработаться, хотя подтверждение результата потерялось.
DLQ не исправляет ошибку автоматически и не гарантирует сохранность навсегда. Для неё нужны срок хранения, мониторинг роста очереди, правила доступа и понятная процедура разбора. Нельзя бездумно повторно отправлять все сообщения: неисправные данные могут снова вызвать сбой или повторить уже выполненную бизнес-операцию.
Количество повторов и задержка — компромисс. Малое число попыток быстрее освобождает основную очередь, но может преждевременно отправить временно неисправное сообщение в DLQ. Большое число попыток лучше переносит кратковременные сбои, но дольше удерживает ресурсы и увеличивает задержку обработки.
Если порядок сообщений значим, изоляция одного сообщения может иметь дополнительное последствие: последующие сообщения могут зависеть от него. В этом случае нужно явно определить, допустимо ли продолжать обработку, или следует приостановить конкретный поток до восстановления сообщения.
Интеграция передаёт изменения заказов из одной системы в другую. Одно сообщение содержит значение, не соответствующее ожидаемой схеме, и каждый повтор завершается ошибкой валидации. При отсутствии DLQ потребитель постоянно возвращает это сообщение, поэтому новые заказы накапливаются в основной очереди.
Рассматривались три варианта. Удаление ошибочного сообщения восстанавливает пропускную способность, но безвозвратно теряет изменение. Бесконечные повторы сохраняют сообщение, но блокируют поток и создают нагрузку. DLQ сохраняет сообщение для расследования и освобождает основную очередь, но требует мониторинга, хранения и процесса повторного запуска.
Выбрали ограниченное число повторов с задержкой и последующим перемещением в DLQ. Для сообщений из DLQ настроили уведомление, проверку схемы перед повторным запуском и отчёт о результате. После исправления источника некорректные сообщения были обработаны повторно, а основная очередь продолжила работу без потери наблюдаемости.
Нет. DLQ снижает риск блокировки основной очереди, но сама может потерять сообщения из-за ограниченного срока хранения, неисправности брокера или ошибочной очистки. Нужны политики хранения, мониторинг, резервирование согласно требованиям надёжности и процедура подтверждённого разбора.
Нет. Ошибки следует классифицировать. Временный сетевой сбой обычно допускает повтор с задержкой, а ошибка схемы или бизнес-валидации чаще всего не исправится повтором. Если повторять неисправимое сообщение бесконечно, система будет тратить ресурсы и может блокировать обработку.
Потребитель мог завершить бизнес-действие, но не успеть подтвердить обработку из-за сбоя соединения или самого процесса. При повторной доставке действие будет выполнено ещё раз, если оно не защищено идемпотентностью или проверкой обработанных идентификаторов. Поэтому перед массовым replay нужно определить семантику доставки и защитить операции от дубликатов.