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

26

表面上它们有些相似，但您的用例将决定哪个工具是合适的。国际海事组织（IMO），如果你可以顺利通过SQS，那么你应该 - 如果它能做到你想要的，它将会更简单和更便宜，但这里有一个更好的解释，从AWS常见问答中给出了适用于这两种工具的例子帮助您决定：

FAQ's

来源

2014-10-29 09:34:29

+1

FYI http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-subscribe-queue-sns-topic.html SQS FIFO不适用于SNS – 2017-10-26 05:49:38

21

最大的优势对我来说是一个事实，即室壁运动是一个重玩队列，SQS是没有的。因此，您可以让多个消费者使用Kinesis的相同消息（或在不同时间使用相同的消费者），在SQS的情况下，一旦消息被消除，它就从该队列中消失。因为这个原因，SQS对于工作队列更好。

这意味着相同的数据记录

来源

2014-10-31 19:10:01

40

室壁运动支持多个消费者的能力可以在相同时间或不同时间在24个小时内以不同的消费者进行处理，在SQS类似的行为可以通过写入到多个队列和消费者可以从多个队列中读取来实现。但是，再次写入多个队列会在系统中增加子秒（几毫秒）延迟。第二，Kinesis提供路由选择功能，使用分区键将数据记录选择性地路由到不同的分片，分区键可以由特定的EC2实例处理，并且可以启用微量批计算（计数&聚合）。

在任何AWS软件上工作都很简单，但SQS是最简单的。使用Kinesis，需要提前提供足够的碎片，动态增加碎片的数量以管理峰值负载并减少以节省管理所需的成本。这是Kinesis的痛苦，SQS不需要这样的事情。 SQS具有无限可扩展性。

来源

2014-11-10 05:11:02 kartik

+9

关于您对SQS的解释。您可以通过在他们面前安装SNS，实现简单的方式将相同的消息发送给多个SQS。 – 2015-06-16 10:15:34

+7

app - > sns话题---> sqs1，sqs2，sqs3 ...？ – kartik 2015-06-16 10:45:20

+4

是的，我指的是这种方法。 – 2015-06-17 08:29:36

48

在了解了一段时间的问题之后，考虑到同样的问题，我发现SQS（带SNS）对于大多数使用情况是首选，除非消息的顺序对您很重要（SQS不保证FIFO消息）。（1）您可以从多个应用程序中读取相同的消息，以及（2）您可以在需要的情况下重新读取消息。

通过使用SNS作为SQS的粉丝，两种优势都可以实现。这意味着消息的制作者只向SNS发送一条消息，然后SNS将消息扇出到多个SQS，每个消费者应用程序一个。通过这种方式，您可以尽可能多的消费者，而不用考虑分片容量。

此外，我们还添加了一个订阅了SNS的SQS，该SNS将持有14天的消息。在通常情况下，没有人从这个SQS中读取数据，但是如果有一个错误让我们想要倒回数据，我们可以很容易地读取来自SQS的所有消息，并将它们重新发送到SNS。而Kinesis只提供7天的保留期。

总之，SNS + SQS非常简单并且提供了大多数功能。 IMO需要一个非常强大的案例来选择Kinesis。

来源

2015-06-16 10:25:52

+1

仅供参考：您可以将Kinesis保留7天。 – 2016-03-22 22:25:56

+0

@DidierA，是的，他们将最大保留策略增加到7天。我会更新答案。谢谢。 – 2016-03-23 08:35:51

+14

近日，AWS宣布了SQS FIFO，可用于消息的时间排序。 – VijeshJain 2016-12-28 21:54:40

6

Kinesis解决了流数据在典型的地图缩小场景中地图部分的问题。虽然SQS不确定这一点。如果您的流数据需要在某个密钥上进行聚合，kinesis会确保该密钥的所有数据都会转到特定分片，并且该分片可以在单个主机上使用，从而使密钥聚合更容易，与SQS相比更容易

来源

2015-11-19 07:21:45

1

我会再补充一件没人提到的东西 - SQS的价格要高出几个数量级。

来源

2015-12-03 19:43:53

+3

你确定吗？从我的计算Kinesis是更昂贵的，但我从来没有使用亚马逊简单的价格计算器才华横溢。 – 2016-03-22 22:27:10

+0

查看aws上的当前定价示例：带有267M邮件的Kinesis约为60美元，而通过SQS发送该邮件的数量将达到107美元。显然，我只是做了一个非常快速的比较，而且这种情况在不同的用例中有很大的不同，但是这个答案绝对应该值得赞扬。 – Moszi 2017-02-08 08:48:53

+1

假设你正在粉丝每天说2个消费者和1亿条消息。 SNS的成本是每天50美元。 SQS成本为40美元/天/消费者或80美元/天。 Kinesis的PUT为每日1.4美元，碎片为0.36美元。即使有100个碎片（100 MB/s，200 MB/s），只需3.60美元/天+ 1.40美元/天。所以Kinesis每天4美元，而SNS/SQS每天130美元。 – 2017-02-27 04:44:49

12

另一件事：Kinesis可以触发一个Lambda，而SQS不能。因此，对于SQS，您必须提供一个EC2实例来处理SQS消息（并在发生故障时处理它），或者您必须有一个预定的Lambda（不会扩大或缩小 - 每分钟只有一个）。

来源

2016-04-22 02:52:29 DenNukem

+1

-1不同意。虽然Kinesis可以触发lambda，但这不会超过预定义的SQS lambda。后者可以无缝扩展（即，如果花费的时间超过一分钟，则第二个lambda会变得更快）。价格是每个计算时间，因此没有明显的差异。如果你需要超过5个并发lambda表达式，那么只需添加多个间隔几秒钟的触发器（使用cron）。这不是使用Kinesis而不是SNS/SQS的理由。 – 2016-12-13 19:05:51

+2

我不确定我是否同意不同意见;] - 您可以安排一个lambda /分钟，这会限制您批处理到达该间隔的消息。Kinesis将允许您立即阅读消息。还是我误解了？ – Moszi 2017-02-08 08:41:52

+0

当需要调用针对SQS的拉姆达时，几个cloudwatch触发器与数百个触发器之间存在巨大差异。 – 2017-12-21 00:46:39

14

从 AWS Documentation

摘录：

我们建议亚马逊的Kinesis流使用的情况下，使用类似下列要求：

路由相关的记录，以相同的记录处理器（如在流式MapReduce中）。例如，当给定密钥的所有记录路由到相同的记录处理器时，计数和聚合更简单。

记录的排序。例如，您希望将日志数据从应用程序主机传输到处理/存档主机，同时保持日志语句的顺序。

多个应用程序能够同时使用同一个流的能力。例如，您有一个应用程序更新实时仪表板，另一个应用程序将数据存档到Amazon Redshift。您希望这两个应用程序同时并独立地使用来自同一个流的数据。

几个小时后才能以相同的顺序使用记录。例如，您有一个计费应用程序和一个在计费应用程序后面运行几个小时的审计应用程序。由于Amazon Kinesis Streams可将数据存储长达7天，因此您可以在计费应用程序后7天运行审计应用程序。

我们建议亚马逊SQS使用例类似于以下要求：

消息语义（如消息级的ACK /失败）和可见性超时。例如，您有一个工作项目队列，并且想要独立跟踪每个项目的成功完成。 Amazon SQS跟踪确认/失败，因此应用程序不必维护持久性检查点/游标。 Amazon SQS将在配置的可见性超时后删除acked消息并重新发送失败的消息。

个别消息延迟。例如，您有一个工作队列，需要延迟安排个别工作。借助Amazon SQS，您可以将单个邮件配置为最多延迟15分钟。

动态增加读取时的并发/吞吐量。例如，您有一个工作队列，并希望添加更多的读者，直到清理积压。借助Amazon Kinesis Streams，您可以扩展到足够数量的碎片（但请注意，您需要提前提供足够的碎片）。

利用Amazon SQS的透明扩展功能。例如，由于偶尔的负载峰值或业务的自然增长，您可以缓冲请求和负载变化。由于每个缓冲的请求都可以独立处理，因此Amazon SQS可以透明地扩展以处理负载，而无需您提供任何配置指示。

来源

2016-07-25 11:00:47 cloudtechnician

2

的定价模式不同，所以根据您的使用情况下，一方或另一方可能会更便宜。使用最简单的情况（不包括SNS）：

SQS为每条消息收费（每个64 KB计为一个请求）。
每小时每个分片的Kinesis费用（1个分片最多可以处理1000条消息或1 MB /秒），也适用于您放入的数据量（每25 KB）。

在目前的价格堵，而不是考虑到自由层，如果你的最大邮件大小每天发送的消息1 GB，室壁运动的成本会高于SQS得多（$ 10.82 /月室壁运动与SQS $ 0.20 /月）。但是如果你每天发送1TB，Kinesis便宜一些（SQS为每月158美元，而201美元/月）。

详细信息：SQS每百万次请求收取0.40美元（每个64KB），因此每GB为0.00655美元。每天1 GB，每月仅为0.20美元;每天1TB，每月超过201美元。

Kinesis收费为每百万次请求0.014美元（每个25KB），因此每GB为0.00059美元。每天1 GB，每月不到0.02美元;每天1 TB，每月约为18美元。然而，Kinesis每小时收费0.015美元。每个1 MB每秒至少需要1个碎片。在每天1GB的情况下，1个碎片将会很多，因此每天将增加0.36美元，总成本为每月10.82美元。每天1 TB，您至少需要13个碎片，每天增加4.68美元，总成本为每月158美元。这些技术的

来源

2017-09-18 20:52:10

+0

我不完全了解为什么指数增长的大小在这里很重要。你能多挖一点吗？这听起来像你有一些我想要的见解。 *编辑*实际上，看着Euguene Feingold的回答，看起来这个（？）有一个非常可靠的辩论。 – Thomas 2017-09-22 14:41:16

+0

对不起，我在计算中犯了一些错误（现在修复，我希望）。 – 2017-09-25 17:19:27

3

语义是不同的，因为他们的目的是支持不同的方案：

SQS：流的项目不彼此相关
室壁运动：流中的物品是彼此相关

让我们通过示例了解差异。

假设我们有一个订单流，对于每个订单我们需要保留一些库存并安排交货。完成此操作后，我们可以安全地从流中移除项目并开始处理下一个订单。完成完成与先前的顺序，然后我们开始下一个。
同样，我们有相同的订单流，但现在我们的目标是按目的地对订单进行分组。一旦我们有10个订单到同一个地方，我们希望将它们交付到一起（交货优化）。现在这个故事是不同的：当我们从流中获取一个新项目时，我们无法完成处理;相反，我们“等待”更多的项目来实现我们的目标。而且，如果处理器进程崩溃，我们必须“恢复”状态（所以不会丢失命令）。

一旦一个项目的处理不能与另一个项目的处理分离，我们必须具有Kinesis语义才能安全地处理所有情况。

来源

2017-11-02 20:58:03

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

回答

相关问题