К списку
Асинхронные системы и очередиSeniorТехническое

Методы проверки обработки poison message и DLQ в асинхронных системах

Краткий ответ

Для тестирования poison message отправляют специально повреждённые сообщения, контролируют количество повторных попыток обработки и проверяют корректность маршрутизации в Dead Letter Queue (DLQ) с последующим мониторингом алертов.

Развёрнуто

Краткий ответ

Тестирование poison message включает отправку некорректных или неправильно сформатированных сообщений в очередь, после чего проверяют логи и количество повторных попыток (ретраев). Важно убедиться, что такие сообщения попадают в DLQ, а система генерирует соответствующие оповещения.


Как это работает

Poison message — это сообщение, которое не может быть обработано из-за ошибок в данных или формате. При поступлении таких сообщений в асинхронную очередь обычно срабатывают политики ретраев: система пытается обработать сообщение несколько раз, после чего направляет его в Dead Letter Queue (DLQ) для дальнейшего анализа.

Тестирование включает следующие шаги:

  • Отправка искажённых payload с намеренно некорректными данными.
  • Проверка, что количество попыток обработки соответствует настройкам ретраев.
  • Подтверждение, что сообщение корректно попадает в DLQ после превышения лимита попыток.
  • Мониторинг алертинга, чтобы убедиться в своевременном уведомлении команды о возникшей ошибке.
Этап Что проверять Инструменты/Методы
Отправка Некорректный payload Скрипты, Postman, кастомные клиенты
Ретрай Количество повторных обработок Логи, метрики очереди
DLQ Корректность маршрутизации message в DLQ Мониторинг очередей, просмотр DLQ
Алерты Срабатывание уведомлений Системы мониторинга (Prometheus, Grafana)

Пример

1. Отправляем сообщение с некорректным JSON:
   { "userId": 123, "data": "\xZZ" }
2. Система пытается обработать 3 раза (по конфигурации ретраев).
3. Сообщение направляется в DLQ.
4. В системе мониторинга появляется алерт о неудачной обработке.

Что важно знать на собеседовании

  • Poison message вызывают механизм повторных попыток (ретраев) в очередях.
  • После превышения лимита ретраев сообщение переносится в Dead Letter Queue.
  • Тестирование должно включать проверку маршрутизации и актуальность алертов.
  • Важно контролировать состояние DLQ, чтобы избежать накопления невалидных сообщений.
  • Настройка алертинга помогает оперативно реагировать на проблемы с обработкой.

Тема: Асинхронные системы и очереди | Уровень: senior