В очереди одно некорректное сообщение блокирует обработку всех последующих. Как изолировать такой сбой, не остановив поток целиком, и какой компромисс это создаёт?
После ограниченного числа повторных попыток проблемное сообщение следует переместить в dead-letter queue (DLQ) или карантин, зафиксировав причину сбоя. Это позволяет продолжить обработку остальных сообщений, но создаёт компромисс: сообщение временно выпадает из основного потока, поэтому его нужно отдельно исследовать и безопасно переигрывать.
В асинхронных интеграциях повторная доставка нужна для временных ошибок: недоступности сервиса, сетевого сбоя или кратковременной перегрузки. Однако бесконечные повторы одного неисправного сообщения превращают механизм надёжности в причину блокировки очереди.
Для этой проблемы появился паттерн dead-letter queue: сообщения, которые не удалось обработать по заданной политике, отделяются от обычного потока и становятся объектом отдельного операционного процесса.
Ошибка сообщения может быть постоянной: нарушена схема, отсутствует обязательная бизнес-сущность или значение не соответствует допустимому диапазону. Повторная попытка в таком случае не изменит результат, но будет занимать ресурсы и задерживать корректные сообщения.
Если просто пропустить сообщение без фиксации, система потеряет бизнес-факт. Если бесконечно повторять его в основной очереди, возникнет poison message — сообщение, отравляющее поток. Поэтому необходимо одновременно сохранить информацию об ошибке и разблокировать обработку независимых сообщений.
Обычно задают ограниченное число попыток с экспоненциальной задержкой. После превышения лимита сообщение перемещают в DLQ вместе с исходным содержимым, идентификатором, временем поступления, числом попыток и классифицированной причиной отказа.
Важно различать временные и постоянные ошибки. Временные ошибки целесообразно повторять, а ошибки контракта или бизнес-данных — быстро направлять в карантин. Автоматическая классификация не идеальна, поэтому политика должна учитывать лимит попыток, задержку и наблюдаемость.
DLQ не является удалением сообщения и не гарантирует исправление проблемы. Нужен процесс: мониторинг количества сообщений, оповещение, анализ причины, исправление данных или потребителя и контролируемое повторное размещение сообщения в основной поток.
Главный компромисс — прогресс потока против строгого порядка. Если сообщения независимы, изоляция одного сообщения обычно безопасна. Если порядок значим для конкретного агрегата, перенос сообщения в DLQ может позволить обработать последующие изменения и привести состояние к некорректному результату; тогда нужно приостановить только соответствующую последовательность либо переигрывать её целиком.
Повторное проигрывание должно быть безопасным: потребитель должен учитывать возможную повторную доставку, а операции — быть идемпотентными или защищёнными проверкой уже применённого сообщения. Иначе исправление DLQ может создать дубликаты побочных эффектов.
Потребитель событий заказов не мог обработать одно сообщение из-за неизвестного значения типа доставки. Очередь сохраняла порядок в одной партиции, поэтому бесконечные повторы задерживали обновления всех следующих заказов.
Рассматривались три варианта. Бесконечные повторы сохраняли порядок, но блокировали поток. Простое отбрасывание сообщения сохраняло пропускную способность, но приводило к потере изменения. Перенос после ограниченного числа попыток в DLQ позволял продолжить обработку, однако требовал расследования и процедуры повторной доставки.
Выбрали третий вариант: для ошибок схемы использовали короткий лимит попыток, сохраняли диагностические метаданные и направляли сообщение в карантин. Для каждой последовательности заказа дополнительно контролировали порядок, поэтому последующие события того же заказа не применялись до устранения проблемного сообщения. В результате независимые заказы продолжили обрабатываться, а ошибочные сообщения стали видимыми для операционной команды вместо бесконечного скрытого повтора.
1. Достаточно ли перенести сообщение в DLQ, чтобы гарантировать отсутствие потери данных?
Нет. Нужно проверить, что сообщение действительно зафиксировано в DLQ, а исходное сообщение не подтверждено до успешного перемещения. Конкретная гарантия зависит от возможностей брокера и обработчика; если перемещение состоит из нескольких независимых операций, возможны отдельные сбои между ними.
Поэтому применяют подтверждаемую операцию перемещения, транзакционные возможности брокера при их наличии либо технический процесс сверки. Также сохраняют исходное содержимое и метаданные, чтобы сообщение можно было восстановить и переиграть.
2. Можно ли автоматически переигрывать все сообщения из DLQ после исправления потребителя?
Не всегда. За время нахождения в DLQ состояние системы могло измениться, а последующие события могли уже частично примениться. Массовое переигрывание способно нарушить порядок, создать дубликаты или повторить устаревшее действие.
Безопасное переигрывание требует определить диапазон сообщений, проверить зависимости и обеспечить идемпотентность потребителя. Иногда нужно переиграть событие, иногда — пересчитать проекцию из актуального источника состояния.
3. Что делать, если порядок сообщений обязателен?
Нельзя безусловно отправлять проблемное сообщение в DLQ и продолжать всю последовательность. Следующие сообщения могут зависеть от результата предыдущего, поэтому состояние конкретного агрегата станет некорректным.
Практический вариант — изолировать только последовательность или ключ, к которому относится ошибка, а остальные ключи обрабатывать параллельно. После исправления проблемного сообщения его и зависимые сообщения переигрывают в исходном порядке. Это сохраняет локальный порядок, не жертвуя доступностью всего потока.