amazon-web-services - 为什么我应该使用 Amazon Kinesis 而不是 SNS-SQS？

Question

我有一个用例，其中将有数据流传入，但我无法以相同的速度使用它并且需要一个缓冲区。这可以使用 SNS-SQS 队列来解决。我发现 Kinesis 解决了相同的目的，那么有什么区别呢？为什么我应该更喜欢(或不应该更喜欢)Kinesis？

Answer 1

请记住，2015 年 6 月的答案是正确的

在研究这个问题一段时间后，考虑到同样的问题，我发现 SQS(带有 SNS)对于大多数用例来说是首选，除非消息的顺序对您很重要(SQS 不保证 FIFO 开启)消息)。

Kinesis 有 2 个主要优势:

1. 您可以从多个应用程序读取同一条消息
2. 如果需要，您可以重新阅读消息。

这两个优点都可以通过使用 SNS 作为 SQS 的扇出来实现。这意味着消息的生产者仅向 SNS 发送一条消息，然后 SNS 将消息扇出到多个 SQS，每个 SQS 对应一个消费者应用程序。通过这种方式，您可以拥有任意数量的消费者，而无需考虑分片容量。

此外，我们还添加了一个订阅 SNS 的 SQS，该 SQS 将保留消息 14 天。在正常情况下，没有人读取此 SQS，但如果出现错误，导致我们想要倒带数据，我们可以轻松地读取此 SQS 中的所有消息，并将它们重新发送到 SNS。而 Kinesis 仅提供 7 天的保留期。

总而言之，SNS+SQS 更简单，并且提供了最多的功能。在我看来，你需要一个非常有力的理由来选择 Kinesis 而不是它。