Если RabbitMQ очередь растет и не уменьшается, значит producer добавляет сообщения быстрее, чем consumer успевает их обрабатывать, либо обработка фактически остановилась. Важно не просто перезапустить брокер, а понять, где именно застряли сообщения.

Сначала нужно посмотреть скорость публикации и потребления, состояние consumer, количество unacked-сообщений, логи обработчика и ресурсы сервера. После этого уже решать: чинить код, менять prefetch, разбирать retry или масштабировать обработчики.

Коротко: что делать

  • Проверить ready, unacked и total messages по проблемной очереди
  • Посмотреть, подключены ли consumer и не падают ли они сразу после старта
  • Найти ошибки обработки конкретных сообщений
  • Проверить CPU, память, диск и лимиты брокера
  • Сделать резервную копию или экспорт важных сообщений перед грубыми действиями

Основные причины

Рост очереди почти всегда связан с одной из четырех зон: producer, consumer, брокер или сама бизнес-логика обработки.

  • Consumer упал, завис или не подтверждает сообщения через ack
  • Prefetch настроен слишком высоко, и сообщения висят в unacked
  • Обработчик падает на одном типе данных и постоянно отправляет сообщение в retry
  • Producer создает всплеск задач, который не покрывается количеством worker
  • RabbitMQ уперся в память, диск, network partition или лимиты соединений

Пошаговая диагностика

Диагностику лучше начинать с метрик очереди, а не с перезапуска. Иначе можно потерять картину сбоя.

  • Открыть management UI и посмотреть ready/unacked/consumers
  • Сверить publish rate и deliver/ack rate
  • Проверить логи worker на исключения и таймауты
  • Найти сообщение, на котором обработчик стабильно падает
  • Проверить dead-letter queue и retry-политику

Как исправить проблему

Исправление зависит от того, очередь копится из-за падения обработчика, медленной обработки или проблем ресурсов.

  • Починить ошибку в consumer и добавить обработку проблемных payload
  • Настроить prefetch так, чтобы worker не забирал слишком много задач сразу
  • Вынести тяжелую операцию в отдельную очередь или добавить worker
  • Настроить DLQ, retry с задержкой и лимит повторов
  • Добавить мониторинг длины очереди, unacked и ошибок consumer

Безопасный план решения

Безопасный план такой: сначала зафиксировать состояние очереди и логи, потом проверить consumer на тестовом сообщении, затем выпускать исправление и только после этого разгружать накопившуюся очередь контролируемо.

Чего не стоит делать

  • Не очищать очередь без понимания, какие сообщения там лежат
  • Не увеличивать бесконечно количество worker, если они падают на одной ошибке
  • Не отключать ack ради быстрого эффекта
  • Не смешивать обычные задачи и бесконечные retry в одной очереди

Что подготовить перед исправлением

  • Название очереди и скрин из RabbitMQ UI
  • Логи consumer за период роста очереди
  • Пример payload проблемного сообщения
  • Код обработчика или доступ к репозиторию

FAQ

Можно ли просто перезапустить RabbitMQ?

Иногда это временно помогает, но если причина в consumer, retry или нагрузке, очередь снова начнет расти. Перезапуск не заменяет диагностику.

Что опаснее: ready или unacked?

Ready означает, что сообщения ждут обработки. Unacked часто опаснее: worker забрал сообщения, но не подтверждает их, завис или обрабатывает слишком долго.

Нужно ли добавлять больше consumer?

Только если текущие consumer работают без ошибок и действительно не успевают. Если они падают, масштабирование размножит проблему.

Когда стоит обратиться за помощью

Обратиться за помощью стоит, если очередь влияет на заказы, уведомления, платежи или интеграции, а причина не видна по метрикам. В такой задаче важно не потерять сообщения.

Итог

Начните с ready/unacked, логов consumer и retry. Если нужна аккуратная диагностика RabbitMQ, Kafka, Redis Streams или фоновых задач, можно написать в Telegram @rabotator_support и прислать симптомы.