将Amazon SQS用于接收相同消息的多个消费者

Question

我有一个主应用程序向SQS Queue发送消息，并希望4个消费者应用程序使用相同消息并对其进行处理，但是他们希望如此

我不确定用于此目的的队列结构。

我看到了标准 SQS，SQS FIFO，（SQS + SNSTopic）和Kenesis的选项

对于我想要的功能，看来（SQS + SNS主题）或Kenesis 都是可行的方法。

但是我还有一个关于标准SQS和SQS FIFO的问题-如果我使用SQS FIFO或标准SQS，是否不可能所有消费者都能获得相同的消息？

我认为我对所有选项感到困惑，并且对队列中的所有可用信息不知所措，但仍对选择哪种架构感到困惑

主要信息来源是Amazon文档和https://www.schibsted.pl/blog/choosing-best-aws-messaging-service/

我在stackoverflow上遇到的一些问题：

Link_1这篇文章回答了将多个使用者与Queue一起使用的问题，但不确定是否解决了多个使用者使用相同消息的问题

Link_2 这回答了为什么可以将Kenesis用于我的情况

Helpful_Info我使用本文只是为了了解它们之间的差异

我真的很感谢您的帮助。我正在尝试阅读尽可能多的书籍，但是如果有人可以帮助我做出正确的决定，我一定会很感激

Answer 1

对于SNS-SQS fanout notifications来说，这似乎是一个完美的用例-消息被发送到SNS“主题”，SNS会将其传递到“订阅”该主题的多个SQS队列中。

一些注意事项：

• 每个使用者应用程序（附加到队列中）将以其自己的速率使用-这意味着一个或多个可能“落后”。通常，只要使用者是独立的，那应该没问题-队列充当缓冲区，因此不会丢失任何信息。
• 如果您需要它们保持同步，则将无法正常工作-您应该只使用一个队列，并使用一个进程来同步轮询该队列并将消息传递给每个应用程序。
• 您可以使用Kinesis（它具有多个使用者）执行类似的逻辑，但是除非您处理非常大的消息量，否则额外的开发复杂性和成本通常不值得
  • Kinesis按数据量（兆字节）计费，而SQS按消息数计费-对您的用例进行数学计算。

除非您需要有关SQS FIFO的订购方面的保证，否则请不要担心。普通SQS已被大致订购，对于大多数用例来说就足够了。

Answer 2

根据您的用例，SNS似乎是一个不错的选择，但是，如果您要保留消息，则可以将SQS与SNS一起使用。