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

Question

我有一个主要应用程序向 SQS 队列发送消息，并希望 4 个消费者应用程序使用相同的消息并按照他们想要的方式处理它

我不确定为此目的使用什么队列架构。

我看到了标准SQS、SQS FIFO、(SQS + SNSTopic) 和 Kenesis 的选项

对于我想要的功能，似乎(SQS + SNS Topic) 或 Kenesis 都是可行的方法。

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

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

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

Link_1这篇文章回答了在队列中使用多个消费者的问题，但不确定它是否解决了多个消费者消费的相同消息的问题

Link_2 这一个回答了为什么 Kenesis 可以用于我的场景

Helpful_Info我使用这篇文章只是为了了解差异

我真的很感激这方面的一些帮助。我正在尝试尽可能多地阅读，但如果有人能帮助我做出正确的决定，我将不胜感激

Answer 1

这看起来像是SNS-SQS 扇出通知的完美用例- 消息被发送到 SNS“主题”，SNS 会将其传送到“订阅”该主题的多个 SQS 队列。

一些注意事项：

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

不要担心 SQS FIFO，除非您需要它在排序方面提供的保证。简单的 SQS 已经大致排序，并且对于大多数用例来说就足够了。

Answer 2

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