2016-04-01 4 views
1

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

Я много искал, но не смог получить номер Max Cap.

Это бесконечно?

+0

Вы запрашиваете максимальное количество сообщений, которые могут быть помещены в очередь, или максимальное количество раз, которое может вызываться 'ReceiveMessage'? –

+0

@JohnRotenstein: да Мне нужно Максимальное количество раз, когда может быть вызван ReceiveMessage. – sarathprasath

ответ

0

В документации message lifecycle ограничений не существует, только если сообщение будет удалено, когда истечет максимальное время удержания сообщения (по умолчанию 4 дня, максимум 14 дней) для очереди.

До тех пор, пока вы не настроите очередь для перемещения сообщений в отдельную «очередь мертвых букв» после настраиваемого максимального количества принимаемых сообщений, по-видимому, будет бесконечно бесконечно, и в этом случае максимальное число разрешено - в том числе количество раз, которое появляется конкретное сообщение при просмотре сообщений о очереди в консоли - 1000. (Минимум 1, конечно).

См: Using Amazon SQS Dead Letter Queues

Там не появляется, чтобы быть документированы ограничение на максимальное количество раз сообщение может быть получено, в противном случае, но есть еще один предел, который будет душить очередь, когда сообщения были повторно получил и их тайм-аут видимости неоднократно позволял истекать (заставляя их снова вернуться к видимости) - каждая очередь поддерживает неограниченное количество сообщений в очереди, но каждая очередь is limited to 120,000 messages in flight at any one time (ожидая истечения срока их видимости).

В противном случае максимальное количество принимаемых сообщений будет ограничено максимальным временем удержания сообщения, умноженным на таймаут видимости. Со значениями по умолчанию 4 дня и 30 секунд это будет (60 & divide; 30) = 11,520.

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

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

Если вы хотите использовать это значение, обратите внимание, что сообщения SQS имеют как «атрибуты» (системные), так и «атрибуты сообщений» (определенные пользователем).

+0

Я полностью осведомлен о очереди мертвой буквы и времени хранения сообщений, но мне очень любопытно узнать предел, если его не бесконечно – sarathprasath

+0

I упомянул о возможностях очереди с мертвой буквой для контраста, поскольку он имеет документированный предел, а также для будущих читателей. Как я уже сказал, нет очевидного документированного лимита. Возможно, @JohnRotenstein имеет внутренний трек и может найти официальный ответ. –

Смежные вопросы