Kinesis和SQS有什么区别？

Question

我知道在线上有很多关于这个问题的材料，但是我还没有找到任何材料可以像我这样的菜鸟清楚地解释这个问题。如果有人可以帮助我理解这些问题之间的主要区别，我将不胜感激。两个服务和用例以及实际示例。谢谢！

Answer 1

这篇文章很好地总结了，imo：

https://sookocheff.com/post/aws/comparing-kinesis-and-sqs/

但是，基本上，如果您不知道需要哪个，请从SQS开始，直到它无法完成您想要的操作为止。 SQS的设置和使用非常简单，几乎不需要任何专业知识就能很好地使用它。

Kinesis需要花费更多的时间和专业知识来进行设置，因此，除非您需要它，否则不要打扰-即使它可以与SQS一起用于许多相同的事情。< / p>

与SQS相比，一个很大的不同是，如果您有多个使用者从队列中进行读取，则每个使用者只会看到他们使用的大量消息-因为其他使用者将无法看到它们。借助Kinesis，许多消费者可以同时访问流，并且每个消费者都可以看到整个街道-因此SQS非常适合执行大量任务，并将片段分发给许多消费者以并行处理（除其他外） ），就像使用Kinesis一样，多个使用者可以读取和查看整个街道，并对流中的所有数据进行处理。

链接的文章比我解释得更好。

Answer 2

Amazon SQS 是一个队列。基本过程是：

• 邮件已发送到队列。他们在那里呆了14天。
• 工作程序可以从队列中请求消息（或最多10条消息）。
• 从队列中检索消息时：
  • 它停留在队列中，但标记为 不可见
  • 当工作人员完成消息处理后，它告诉SQS从队列中删除消息
  • 如果工作人员未在队列的可见性超时时间段中不删除消息，则该消息重新出现在队列中供其他工作人员使用处理
  • 如果需要，工作人员可以定期告诉SQS 使消息不可见，因为它仍在处理中

因此，一旦处理完消息，便将其删除。

在 Amazon Kinesis 中，一条消息发送到流。流分为碎片（可以将其视为迷你流）。收到消息后，Kinesis将消息按顺序存储。然后，工作人员可以从流的开头或流中的特定位置请求消息。例如，如果它已经处理了5条消息，则可以要求输入6条消息。邮件会在流中保留一段时间（例如24小时）。

我喜欢像条带那样思考-电影中的每个帧都保持整齐。您可以从头开始播放电影，也可以快进到中间然后从那里开始播放。此外，您可以快退到较早的部分并观看。 Kinesis流同样如此，并且可以同时从流的各个部分读取多个消费者。

那么，该选择哪个？

• 如果先使用一条消息然后将其丢弃，则队列可能是更好的选择。
• 如果保留邮件顺序很重要和/或将多次使用邮件，则信息流可能会更好。

Answer 3

我会根据实际经验给出一个简单的答案：

1. 将 SQS 视为临时存储服务。用例：

   • 管理具有不同队列优先级
   的数据
   • 存储数据有限的时间
   • Lambda DLQ
   • 通过长时间轮询
   降低成本
   • 创建 FIFO

2. 考虑 Kinesis 作为大量实时数据的收集器。用例：

   来自不同来源的
   • 非常大的数据流
   • 仅启用 Firehose 的数据备份（您免费获得一个数据湖）
   • 在收集阶段将Kinesis Analytics
   集成在一起，立即获取统计信息
   • 具有检查点，以在DynamoDB中跟踪已处理/失败的记录

注意：考虑到两种服务都可以很容易地与Lambda函数集成，因此SQS和Kinesis都可以解决很多用例。无论如何，我试图列出一些用例，在这些用例中，我发现两个用例之一的性能要比另一个更好。希望对您有所帮助：）