Использование Amazon SQS для нескольких потребителей, получающих одно и то же сообщение

Question

У меня есть одно основное приложение, отправляющее сообщения в очередь SQS, и я хочу, чтобы 4 пользовательских приложения потребляли одно и то же сообщение и обрабатывали его, однако они хотят

Я не уверен, для какой архитектуры очередииспользовать для этой цели.

Я вижу вариант Стандарт SQS, SQS FIFO, (SQS + SNSTopic) и Kenesis

Для функциональности, которая мне нужна, она выглядит как (SQS + SNS Topic) или Kenesis .

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

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

Основной источник информации - документы Amazon и https://www.schibsted.pl/blog/choosing-best-aws-messaging-service/

Некоторые извопросы, которые я рассмотрел на stackoverflow:

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

Link_2 Этот ответ объясняет, почему Kenesis можно использовать для моего сценария

Helpful_Info Я использовал эту статью только для того, чтобы понять различия

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

Answer 1

Это выглядит как идеальный вариант использования для уведомлений о разветвлении SNS-SQS - сообщения отправляются в «тему» ​​SNS, и SNS доставляет их в несколько очередей SQS, которые «подписаны» на этоtopic.

Некоторые примечания:

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

Не беспокойтесь о SQS FIFO, если вам не нужны гарантии, которые он предоставляет при оформлении заказа.Обычный SQS уже приблизительно заказан, и его будет достаточно для большинства случаев использования.

Answer 2

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