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