Сбой автоматического масштабирования рабочего уровня Amazon SQS

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

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

Я попытался использовать URL-адрес состояния монитора, как и в обычном веб-приложении, но, похоже, это не работает, поскольку сообщения продолжают отправляться независимо.

Есть ли способ установить задержку для любого нового экземпляра с автоматическим масштабированием, прежде чем он начнет получать сообщения из очереди?


amazon-elastic-beanstalk amazon-sns amazon-sqs
person northernMonkey    schedule 20.02.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я не уверен, как экземпляр «получает сообщения» до того, как он будет готов, если вы на самом деле не используете SNS для PUSH сообщений в конечную точку, в отличие от конечной точки (экземпляра) PULL сообщения из очереди.

Если вы отправляете сообщения через SNS, то самое простое решение состоит в том, чтобы экземпляр ОПРОСИЛ очередь SQS для сообщений, когда он готов их обработать - гораздо безопаснее и надежнее, и, очевидно, экземпляр может решить сам, когда он будет готов к работе.

Мне также кажется, что ваше решение не спроектировано должным образом. Если случайная обработка одного и того же сообщения дважды вызовет проблемы в вашей базе данных, значит, вы неправильно используете SQS. Работа, которую выполняет SQS, должна быть идемпотентной, т. е. она должна обрабатываться более одного раза, не вызывая проблемы. Даже когда все работает на 100% правильно, на вашей стороне и в AWS, возможно, одно и то же сообщение будет отправлено вашим воркерам более одного раза — вы не можете предотвратить это — и ваша обработка должна быть в состоянии справиться с этим изящно. .

person E.J. Brennan    schedule 22.02.2015
comment
Я принимаю комментарии относительно того, что наш SQS является идемпотентным, и сам много раз подчеркивал это. К сожалению, кодовая база, которую мы унаследовали, потребует масштабного пересмотра, чтобы учесть это (например, во время процесса он открывает и закрывает несколько транзакций БД), поэтому, пока это не произойдет, мы должны работать с тем, что у нас есть. Вернуться к обрабатываемым сообщениям, когда оно будет готово. У нас есть наше приложение workerTier в экземпляре EB, и оно связано с SQS, поэтому в нашем приложении нет кода, который опрашивает сообщения, все это обрабатывается серверной частью workerTier с помощью магии AWS. - person northernMonkey; 25.02.2015

arrow_upward
1
arrow_downward

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

person flovilmart    schedule 27.03.2015