Как работает Amazon SQS в этом сценарии?

Потребитель слушает в очереди (FIFO или стандартная очередь), Продюсер создает сообщение в очереди.Как работает Amazon SQS в этом сценарии?

Очередь ASAZON SQS автоматически удаляет сообщение из очереди после получения подтверждения от потребителя? Есть ли способ/конфигурация, где очередь хранит сообщение, а не удаляет его и гарантирует, что он не будет доставлен снова.
Производитель производит сообщение в очереди. Потребитель становится в сети из-за проблемы с сетью. Через некоторое время он/она возвращается в онлайн. будет ли очередь отправлять сообщение потребителю, когда он будет в сети? Я думаю, да, поскольку очередь не получила ACK от потребителя.

источник

2017-02-04 user3198603

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

Sqs не беспокоится о состоянии онлайн-статуса потребителя. Потребитель периодически опроса sqs для новых товаров. Если сообщение доступно, оно выдается. Как только потребитель будет сделан, он вызывает sqs для удаления этого сообщения. Затем снова опробуйте новое сообщение.

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

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

Надеюсь, что это поможет.

источник

2017-02-04 03:56:54 inquisitive

Вы сказали: «Потребитель периодически опросит SQS для новых товаров». Есть ли способ, которым потребитель может слушать в очереди, а затем очередь может подтолкнуть его к клиенту, а не потребитель, потянув его? Поскольку модель pull не будет работать для масштабируемого приложения. – user3198603

@ user3198603 между этим комментарием и вашим оригинальным вопросом, похоже, что вы вообще не читали документацию. Сообщения передаются потребителю по длинному запросу HTTP/S-соединения ... как описано в [FAQ по SQS] (https://aws.amazon.com/sqs/faqs/). –

@ user3198603, идея о том, что масштабируемость страдает от натяжения, неверна без подходящей базы. Он страдает только тогда, когда многие работники попадают на один сервер за очень короткий промежуток времени. С sqs два фактора устраняются таким образом (1) нет ни одного сервера, а флота серверов. Хиты распределены (2) вы не попали на высокой частоте. Частота понижается механизмом длинного опроса. – inquisitive

Как работает Amazon SQS в этом сценарии?

ответ

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