Параллельный опрос стандартной очереди AWS SQS - обработка сообщений идет слишком медленно - PullRequest
0 голосов
/ 23 ноября 2018

У меня есть модуль, который опрашивает очередь AWS SQS с заданными интервалами по одному сообщению за раз с ReceiveMessageRequest.Ниже приведен метод:

public static ReceiveMessageResult receiveMessageFromQueue() {

    String targetedQueueUrl = sqsClient.getQueueUrl("myAWSqueueName").getQueueUrl();
    ReceiveMessageRequest receiveMessageRequest = new ReceiveMessageRequest(targetedQueueUrl)
            .withWaitTimeSeconds(10).withMaxNumberOfMessages(1);
    return sqsClient.receiveMessage(receiveMessageRequest);
}

После получения и обработки сообщения оно удаляется из очереди с помощью DeleteMessageResult.

public static DeleteMessageResult deleteMessageFromQueue(String receiptHandle) {

    log.info("Deleting Message with receipt handle - [{}]", receiptHandle);
    String targetedQueueUrl = sqsClient.getQueueUrl("myAWSqueueName").getQueueUrl();
    return sqsClient.deleteMessage(new DeleteMessageRequest(targetedQueueUrl, receiptHandle));

}

Я создал исполняемый файл JAR.который развернут примерно в 40 экземплярах и активно опрашивает очередь.Я мог видеть, что каждый из них получает сообщения.Но в консоли AWS SQS я вижу только цифры 0, 1, 2 или 3 в столбце «сообщения в полете».Почему это так, даже когда более 40 разных потребителей получают сообщения из очереди?Также количество сообщений, доступных в очереди, уменьшается очень медленно.

Ниже приведены параметры конфигурации очереди.

Default Visibility Timeout: 30 seconds
Message Retention Period:   4 days
Maximum Message Size:   256 KB
Receive Message Wait Time:  0 seconds
Messages Available (Visible):   4,776
Delivery Delay: 0 seconds
Messages in Flight (Not Visible):   2
Queue Type: Standard
Messages Delayed:   0
Content-Based Deduplication:    N/A 

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

ОБНОВЛЕНИЕ:

Все экземпляры EC2 и SQS находятся в одном регионе.Потребители (jar-файл, который опрашивает очередь) запускаются как часть сценария запуска экземпляра EC2.И у него есть запланированное задание, которое опрашивает очередь каждые 12 секунд.Прежде чем я помещаю сообщения в очередь, я раскрутил 2-3 экземпляра.(У нас могут быть некоторые уже запущенные экземпляры в это время - это добавляет количество получателей (ограничено до 50) для очереди. При получении сообщения оно выполнит некоторые задачи (включая некоторые операции с БД, анализ данных и вычисления, файл отчета).Генерация и загрузка отчета в S3 и т. д.), и это займет около 10-12 секунд. После этого он удалит сообщение из очереди. Ниже приведен скриншот метрик SQS за последнюю 1 неделю (из SQS).консоль мониторинга).

SQS Metrics for the targeted Queue for last 1 week

1 Ответ

0 голосов
/ 24 ноября 2018

Я сделаю все возможное, с предоставленной информацией.Более подробные сведения о логике цикла обработки, настройке региона и показателях (см. Ниже) помогут улучшить этот ответ.

Я создал исполняемый файл JAR, который развернут примерно в 40 экземплярах и активноопрос очередиЯ мог видеть, что каждый из них получает сообщения.Но в консоли AWS SQS я вижу только цифры 0, 1, 2 или 3 в столбце «сообщения в полете».Почему это так, даже когда более 40 разных потребителей получают сообщения из очереди?Кроме того, количество сообщений, доступных в очереди, уменьшается очень медленно.

Почему сообщения не обрабатываются быстро, даже если есть несколько потребителей?Нужно ли изменять какие-либо параметры очереди или что-то в запросах на получение / удаление сообщений?

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

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

  1. Если вызапуск нового процесса для каждого получения-процесса-удаления, эти накладные расходы существенно замедляют работу.Я предполагаю, что вы этого не делаете, и каждый хост выполняет цикл внутри одного процесса
  2. Убедитесь, что ваш цикл обработки не приводит к фатальным последствиям и перезапускается (фактически превращая его в описанный выше случай).
    • Полагаю, вы также убедились, что ваши процессы не выполняют большую часть работы вне обработки сообщений.
  3. Вам следует сгенерировать некоторые метрики на стороне клиента, чтобыуказать, сколько времени запросы SQS принимают на каждом хосте.
    • Cloudwatch частично сделает это за вас, но фактические метрики на стороне клиента всегда полезны.
    • Рекомендуют следующие основные метрики: (1) задержка получения, (2) задержка процесса, (3) удалить задержку, (4) задержку всего цикла сообщений (5) счетчики успеха / неудачи
  4. Ваши экземпляры EC2 (хосты, выполняющие обработку) должны находиться в том же регионе, что и очередь SQS,Если вы делаете межрегиональные звонки, это повлияет на вашу задержку.
    • Убедитесь, что эти хосты имеют достаточные ресурсы ЦП / памяти для обработки
    • В качестве оптимизации я рекомендую использовать больше потоков на хост и меньше хостов - повторное использование клиентских подключений и максимальное использование вашеговычислительные ресурсы всегда лучше.
  5. Убедитесь, что не было никаких перебоев или продолжающейся проблемы, когда вы выполняли тест
  6. Выполните getQueueUrl только один раз за время жизниваше приложение, на каком-то этапе инициализации.Вам не нужно вызывать это повторно, так как это будет один и тот же URL
    • На самом деле это было первое, что я заметил в вашем коде , но это далеко здесь, потому что вышепроблемы будут иметь большее влияние, если они будут причиной.
  7. Если ваша обработка сообщений невероятно короткая (меньше времени, чем требуется для извлечения и удаления сообщения), то в итоге вы получитеВаши хозяева тратят большую часть своего времени на получение сообщений.Метрики по этому тоже важны.
    • В этом случае вам, вероятно, следует выполнять пакетную выборку, а не поочередно.
    • На основании количества сообщений в вашей очереди и комментария, что он идет медленно, звучит так, будто это не так.
  8. Убедитесь, что все хостыфактически попадает в ту же очередь (а не какую-либо бета / гамма версию или более старую версию, которую вы использовали для тестирования в какой-то момент)

Дальнейшее примечание:

  • Другой ответ предлагает в качестве потенциальной причины тайм-аут видимости - это категорически неверно .Тайм-аут видимости не блокирует очередь - он only влияет на то, как долго сообщения остаются "в полете", прежде чем другой receiveMessageRequest сможет получить это сообщение.
  • Вы бы рассмотрели возможность уменьшить это, если хотите попробовать обработать ваши сообщения раньше в случае ошибок / медленных процессоров.
...