AWS SQS - взаимосвязь между числом потребителей очереди и количеством сообщений в полете

Question

У меня есть стандартная очередь AWS SQS, и несколько экземпляров EC2 (~ 2K) активно опрашивают эту очередь с интервалом в 2 секунды. Я использую AWS Java SDK для опроса очереди и использую ReceiveMessageRequest с одним сообщением в ответ на каждый запрос.

Я ожидаю, что число входящих сообщений , отображаемое в консоли SQS, представляет собой количество сообщений, полученных потребителями и еще не удаленных из очереди (т. Е. Это число активных сообщений в процесс в одно мгновение). Но проблема в том, что количество сообщений в полете намного меньше, чем количество потребителей, которых я имею в одно мгновение. Как я уже упоминал, у меня ~ 2 000 потребителей, но я вижу только количество сообщений в полете в aprox. Диапазон 300-600.

Является ли мое предположение неверным, что сообщения в полете равны количеству сообщений, обрабатываемых в настоящее время. Также есть ли какие-либо ограничения в SQS / EC2 или SQS Java SDK, ограничивающие количество сообщений, которые могут быть обработаны в одно мгновение?

Answer 1

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

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

Answer 2

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

Из вашего примера 2000 потребителей, опрашивающих с интервалом в 2 с, но только с максимальным значением в 600 в сообщениях о полете - некоторая очень грубая математика (600/2000=0.3) будет означать, что ваши хосты тратят только 30% своего времени на фактическую обработку. В простейшем случае это может произойти, если опрос / обработка / удаление сообщения занимает всего 600 мс, а среднее время простоя между удалением одного сообщения и получением следующего составляет 1400 мс.

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

• Иметь достаточно сборщиков (использующих пакетный API ReceiveMessage), чтобы разблокировать процессоры
• Ограничить размер очереди в памяти между сборщиками и процессорами, чтобы один хост не отправлял слишком много сообщений (блокируя их обработку другими хостами)
• Добавьте столько процессорных потоков, сколько может обработать ваш хост
• Сохраняйте метрики относительно того, сколько времени занимает обработка, и предоставьте возможность прервать обработку, если она превышает определенный порог времени (связанный с тайм-аутом видимости)
• Использовать достаточное количество средств удаления, чтобы не отставать от обработки (также используя пакетный API DeleteMessage)

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

Другие вопросы для рассмотрения:

• Использовать длинный опрос - установить свойство WaitTimeSeconds в API ReceiveMessage, чтобы минимизировать пустые ответы
• Когда вы видите низкую пропускную способность, убедитесь, что ваша очередь насыщена - если в очереди очень мало элементов и много процессоров, многие из этих процессоров будут бездействовать в ожидании сообщений.
• Не опрашивать с интервалом - опрашивайте, как только вы закончите обработку предыдущих сообщений.
• Используйте пакетирование для запроса / удаления нескольких сообщений одновременно, сокращая время, затрачиваемое на вызовы в оба конца на SQS