Максимизация пропускной способности сообщений: Автоматический и ручной режимы подтверждения

Режим подтверждения RabbitMQ — это одна из тех настроек, которая выглядит незначительной в клиентском коде, но имеет огромные эксплуатационные последствия. Он определяет, когда брокеру разрешается забыть сообщение. Этот выбор влияет на пропускную способность, нагрузку на память, повторные попытки, дублирование работы и то, что происходит, когда потребитель выходит из строя на полпути обработки.

Короткая версия такова: автоматическое подтверждение быстрое, потому что RabbitMQ считает сообщение обработанным сразу после его доставки. Ручное подтверждение безопаснее, потому что ваш потребитель явно сообщает RabbitMQ, когда обработка прошла успешно. Большинство производственных систем должны начинать с ручных подтверждений и настраивать предвыборку, прежде чем даже рассматривать auto-ack.

Что на самом деле означает подтверждение

Подтверждение — это не бизнес-квитанция. Это сигнал на уровне брокера. Когда потребитель отправляет basic.ack, он сообщает RabbitMQ: эту доставку можно удалить из очереди.

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

Автоматическое подтверждение

При auto-ack клиент подписывается с включенным автоматическим подтверждением. RabbitMQ отправляет сообщение и немедленно считает его успешно доставленным. Потребитель не отправляет последующий basic.ack.

Во многих клиентских библиотеках эта настройка отображается как логическое значение при потреблении. Например, Java использует autoAck в basicConsume; несколько библиотек предоставляют ту же идею с немного разными названиями.

Привлекательность очевидна. Меньше операций протокола и меньше бухгалтерии. Потребитель может принимать сообщения так быстро, как RabbitMQ и сеть могут их доставить. Для телеметрии, временных обновлений состояния или одноразовых рабочих нагрузок это может быть приемлемо.

Риск также очевиден, как только вы увидели его в производстве. Если потребитель получает десять тысяч сообщений, а затем падает до обработки своего буфера в памяти, эти сообщения исчезают из очереди. RabbitMQ не может доставить их повторно, потому что они уже были автоматически подтверждены.

Auto-ack разумен, когда сообщение некритично, может быть регенерировано или представляет собой живой поток, где старые данные бесполезны. Примеры включают метрики с максимальными усилиями, обновления присутствия в пользовательском интерфейсе или события журнального типа, где отдельный устойчивый конвейер является источником записи. Это плохой выбор для платежей, заказов, изменений запасов, обновлений учетных записей или заданий, где пропущенное сообщение создает ручную очистку.

Ручное подтверждение

При ручном подтверждении RabbitMQ хранит доставленные сообщения в неподтвержденном состоянии, пока потребитель не ответит. Если соединение потребителя закрывается до подтверждения, RabbitMQ повторно ставит в очередь эти неподтвержденные сообщения и может доставить их снова.

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

Безопасный цикл потребителя обычно следует такой форме:

получить сообщение
проверить полезную нагрузку
выполнить устойчивую работу
зафиксировать транзакцию базы данных или внешний побочный эффект
подтвердить сообщение

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

Предвыборка — это реальный рычаг пропускной способности

Многие команды сравнивают auto-ack и manual ack, видят, что manual ack медленнее с настройками по умолчанию, и делают неправильный вывод. Недостающая часть — это предвыборка.

Предвыборка RabbitMQ, настраиваемая с помощью basic.qos, ограничивает количество неподтвержденных сообщений, которые потребитель может одновременно удерживать. При manual ack и prefetch=1 потребитель получает одно сообщение, обрабатывает его, подтверждает и только затем получает другое. Это безопасно, но оставляет пропускную способность неиспользованной для любого работника, который может обрабатывать параллельно или терпеть небольшой локальный буфер.

Более высокая предвыборка позволяет RabbitMQ поддерживать занятость потребителя:

prefetch = worker_concurrency * expected_work_buffer

Если работник обрабатывает 8 заданий одновременно, предвыборка 16 или 32 является разумной отправной точкой. Если каждое сообщение большое или обработка требует много памяти, начните с меньшего значения. Если каждое сообщение крошечное, а обработка в основном представляет собой сетевой ввод-вывод, большее число может помочь.

Не копируйте случайную предвыборку 250 в каждый сервис. Высокая предвыборка может вызвать неравномерное распределение. Один потребитель может получить большую партию и сидеть на ней, в то время как другие потребители простаивают. Это также увеличивает всплески повторной доставки, когда потребитель умирает. RabbitMQ повторно поставит в очередь все неподтвержденные доставки от этого соединения, что может заставить другого работника внезапно унаследовать большой бэклог.

Компромиссы пропускной способности и безопасности

Вот практическое сравнение:

Режим	Что делает RabbitMQ	Сильная сторона	Основной риск
Auto-ack	Удаляет сообщение при доставке	Самая высокая сырая скорость доставки	Потеря работы, если потребитель падает
Manual ack, низкая предвыборка	Ждет каждого подтверждения, прежде чем отправить больше	Простое поведение при сбое	Недоиспользованные потребители
Manual ack, настроенная предвыборка	Держит контролируемое количество сообщений в полете	Хорошая пропускная способность с восстановлением	Требует идемпотентных обработчиков и дизайна повторных попыток

Важная деталь заключается в том, что ручное подтверждение не обязательно должно быть медленным. Плохо настроенное manual ack медленное. Manual ack с разумной предвыборкой, параллельными работниками и короткими транзакциями базы данных может обрабатывать серьезный объем, сохраняя при этом поведение восстановления.

Конкретный рабочий процесс настройки

Начните с manual ack и консервативной предвыборки:

prefetch = от 1 до 4 на рабочий поток

Измерьте утилизацию потребителя, глубину очереди, время обработки сообщения, память и повторные доставки. Если потребители простаивают, а в очереди есть сообщения, увеличьте предвыборку. Если память растет или один потребитель накапливает работу, уменьшите ее. Если всплески повторных доставок, проверьте сбои, тайм-ауты и поведение nack, прежде чем снова менять предвыборку.

Следите также за брокером. Высокая пропускная способность — это не только число потребителей. Дисковый ввод-вывод, подтверждения издателя, тип очереди, размер сообщения, долговечность, зеркалирование или репликация кворума, а также пропускная способность сети — все это влияет на результат. Режим подтверждения — это один рычаг в более крупной системе.

Обработка ошибок важнее, чем флаг

Потребитель manual-ack без плана действий при сбое построен только наполовину. При успехе — подтверждайте. При временном сбое — nack и повторная постановка в очередь только если немедленная повторная попытка имеет смысл. При ядовитом сообщении — отклоните или nack без повторной постановки в очередь и направьте его в обмен мертвых писем, если он настроен.

Также установите политику максимального количества повторных попыток вне основной очереди потребителя. RabbitMQ волшебным образом не узнает, что неправильно отформатированное сообщение JSON не удалось 5 раз, если ваш дизайн не отслеживает попытки через заголовки, очереди повторных попыток или состояние приложения.

Что бы я выбрал по умолчанию

Для бизнес-событий и фоновых заданий используйте ручные подтверждения. Настройте предвыборку на основе параллелизма работников и памяти. Сделайте обработчики идемпотентными. Добавьте отправку в мертвые письма, прежде чем плохое сообщение научит вас, почему бесконечные немедленные повторные попытки болезненны.

Используйте auto-ack только тогда, когда потеря приемлема и задокументирована. Это предложение должно быть легко защищать во время разбора инцидента. Если команда будет расстроена, обнаружив, что доставленное, но необработанное сообщение исчезло, auto-ack — неправильная настройка.

Размер сообщения меняет ответ

Значение предвыборки, которое прекрасно работает для сообщений размером 2 КБ, может быть безрассудным для сообщений размером 5 МБ. Предвыборка контролирует количество, а не общее количество байтов. Если один потребитель может удерживать 100 неподтвержденных сообщений, и каждое сообщение большое, локальное потребление памяти может быстро вырасти. Брокер также должен отслеживать эти доставки, пока они не будут подтверждены.

Когда сообщения большие, начните с более низкой предвыборки и измерьте резидентную память в процессе потребителя. Если возможно, держите тело сообщения маленьким и храните большие полезные нагрузки в другом месте, например, в объектном хранилище, при этом сообщение несет ссылку и контрольную сумму. Этот дизайн не всегда уместен, но он не дает брокеру стать транспортом для больших файлов.

Пакетное подтверждение может уменьшить протокольный обмен

Многие клиентские библиотеки позволяют вам подтверждать несколько доставок одним подтверждением, используя флаг multiple. Это может уменьшить накладные расходы протокола, когда потребитель обрабатывает сообщения по порядку и может безопасно подтвердить диапазон тегов доставки.

Загвоздка в обработке сбоев. Если вы обрабатываете сообщения параллельно, порядок тегов доставки может не соответствовать порядку завершения. Подтверждение нескольких сообщений, потому что последнее удалось, может случайно подтвердить более ранние сообщения, которые все еще выполняются или завершились сбоем. Для параллельных работников подтверждение каждого сообщения часто проще и безопаснее.

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

Следите за неподтвержденными сообщениями во время инцидентов

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

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

С помощью интерфейса управления или rabbitmqctl посмотрите на:

rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers

Если messages_unacknowledged высокое, а потребители живы, проверьте журналы потребителя и дампы потоков, прежде чем менять настройки брокера. Брокер, возможно, просто ждет, пока приложение завершит работу.

Повторная доставка — это нормально, но повторяющаяся повторная доставка — это признак проблемы

Manual ack означает, что сообщения могут быть доставлены повторно после сбоя потребителя. Это ожидаемо. Чего вы не хотите, так это чтобы одно и то же ядовитое сообщение доставлялось, терпело неудачу, повторно ставилось в очередь и доставлялось снова бесконечно.

Добавьте достаточно метаданных для диагностики повторных попыток. Некоторые команды используют заголовки для отслеживания попыток. Другие перемещают сбои в обмен повторных попыток, а затем в очередь мертвых писем после достижения лимита. Точный шаблон варьируется, но операционная цель одна и та же: временные сбои получают еще один шанс, постоянные сбои становятся видимыми и перестают блокировать полезную работу.

Когда обработчик не идемпотентен, повторная доставка становится опасной. Предположим, работник списывает средства с карты, а затем падает перед подтверждением. RabbitMQ доставит сообщение повторно. Если обработчик спишет средства снова, брокер не создал ошибку; он выявил отсутствующий ключ идемпотентности. Для внешних побочных эффектов храните устойчивый идентификатор операции и делайте побочный эффект безопасным для повторения.

Подтверждения издателя — это отдельная проблема

Подтверждения потребителя сообщают RabbitMQ, что потребители обработали доставки. Подтверждения издателя сообщают издателям, что RabbitMQ принял опубликованные сообщения. Они решают противоположные стороны потока.

Система может использовать manual consumer ack и все равно терять сообщения во время публикации, если издатели используют fire-and-forget без подтверждений и соединение обрывается в неподходящий момент. Точно так же подтверждения издателя не защищают работу после того, как потребитель получил сообщение. Для надежных конвейеров используйте оба, где этого требует бизнес-кейс: подтверждения на стороне публикации, manual ack на стороне потребления, долговечные очереди, где это уместно, и идемпотентная обработка на уровне приложения.

Тип очереди и долговечность влияют на ту же дискуссию о пропускной способности

Режим подтверждения не существует изолированно. Временная классическая очередь с непостоянными сообщениями имеет другой профиль производительности и безопасности, чем долговечная очередь кворума с постоянными сообщениями. Если вы тестируете auto-ack на одноразовой очереди, а затем применяете результат к долговечной производственной очереди, сравнение бесполезно.

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

Честный тест сохраняет эти переменные стабильными:

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

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

Параллелизм потребителя должен соответствовать работе

Если каждое сообщение проводит большую часть времени в ожидании HTTP или базы данных, потребитель может выиграть от параллельной обработки. Если каждое сообщение требует много процессора, слишком большой параллелизм может замедлить каждое сообщение. Предвыборка должна следовать этой реальности.

Для однопоточного потребителя предвыборка 100 может просто создать большую локальную комнату ожидания. Для работника с 20 активными слотами обработки предвыборка 40 может поддерживать эти слоты заполненными. Для процесса, связанного с процессором, с четырьмя ядрами, параллелизм 100 может увеличить переключение контекста без улучшения пропускной способности.

Измеряйте время обработки внутри потребителя, а не только глубину очереди. Добавьте журналы или метрики для времени получения, времени начала, времени завершения, времени подтверждения, причины сбоя и флага повторной доставки. Эти временные метки значительно упрощают определение того, ожидает ли работа в RabbitMQ, внутри потребителя или застряла в нижестоящей системе.