为什么我应该使用亚马逊Kinesis而不是SNS-SQS?

从表面上看，它们有点相似，但是用例将决定哪种工具是合适的。在我看来，如果你可以使用SQS，那么你应该——如果它能做你想做的事情，它会更简单、更便宜，但这里有一个来自AWS FAQ的更好解释，它给出了两个工具的适当用例示例，以帮助你决定:

< a href = " http://aws.amazon.com/kinesis/faqs/ " >常见问题的< / >

Kinesis支持多消费者功能，这意味着相同的数据记录可以在同一时间或24小时内不同的时间在不同的消费者处处理，SQS中的类似行为可以通过写入多个队列实现，消费者可以从多个队列中读取。然而，再次写入多个队列将在系统中增加几秒(几毫秒)的延迟。

其次，Kinesis提供了路由功能，可以使用分区键将数据记录选择性地路由到不同的分片，这些分区键可以由特定的EC2实例处理，并可以启用微批处理计算{计数&聚合}。

使用任何AWS软件都很容易，但使用SQS是最简单的。使用Kinesis，需要提前提供足够的碎片，动态增加碎片数量以管理尖峰负载，并减少以节省管理所需的成本。这是运动的疼痛，SQS不需要这样的事情。SQS是无限可伸缩的。

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

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

Kinesis有2个主要优势:

1. 您可以从多个应用程序读取相同的消息
2. 如果需要的话，您可以重新阅读邮件。

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

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

总之，SNS+SQSs更简单，提供了大部分功能。在我看来，你需要一个非常有力的案例来选择Kinesis。

Kinesis解决了流数据典型的映射缩减场景中的映射部分问题。而SQS并不确定这一点。如果你有需要在一个键上聚合的流数据，kinesis可以确保该键的所有数据都到一个特定的分片，并且该分片可以在单个主机上使用，这使得在键上的聚合比SQS更容易

我还要补充一件没人提到过的事情——SQS要贵几个数量级。

另一件事:Kinesis可以触发Lambda，而SQS不能。因此，对于SQS，您要么必须提供一个EC2实例来处理SQS消息(并在失败时处理它)，要么必须有一个预定的Lambda(它不能扩大或缩小—每分钟只能得到一个)。

编辑:这个答案不再正确。自2018年6月起，SQS可以直接触发Lambda

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

节选自AWS的文档:

我们推荐Amazon Kinesis Streams用于需求类似于以下的用例:

• 将相关记录路由到相同的记录处理器(如MapReduce流)。例如，当给定键的所有记录都路由到相同的记录处理器时，计数和聚合就更简单了。

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

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

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

对于需求类似于以下的用例，我们建议使用Amazon SQS:

• 消息传递语义(例如消息级别的ack/fail)和可见性超时。例如，您有一个工作项队列，并希望独立地跟踪每个项的成功完成情况。Amazon SQS跟踪ack/fail，因此应用程序不必维护持久的检查点/游标。Amazon SQS将在配置的可见性超时后删除被封的消息并重新传递失败的消息。

• 单个消息延迟。例如，您有一个作业队列，需要对单个作业进行延迟调度。使用Amazon SQS，您可以将单个消息配置为最多15分钟的延迟。

• 在读取时动态增加并发/吞吐量。例如，您有一个工作队列，希望添加更多的读取器，直到清除积压。使用Amazon Kinesis Streams，您可以扩展到足够数量的碎片(但是请注意，您需要提前提供足够多的碎片)。

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

定价模型是不同的，因此根据您的用例，一种或另一种可能更便宜。使用最简单的情况(不包括SNS):

• SQS对每个消息收费(每个64 KB算作一个请求)。
• Kinesis对每个分片每小时收费(一个分片最多可以处理1000条消息或1 MB/秒)，也对您放入的数据量收费(每25 KB)。

考虑到当前的价格，不考虑免费级别，如果您以最大消息大小每天发送1gb的消息，Kinesis的成本将远远高于SQS (Kinesis每月10.82美元，SQS每月0.20美元)。但如果你每天发送1tb, Kinesis会稍微便宜一些($158/月vs. SQS $201/月)。

详细信息:SQS每百万请求收费0.40美元(每次64 KB)，因此每GB收费0.00655美元。以每天1gb计算，每月不到0.20美元;按每天1tb计算，每月的费用略高于201美元。

Kinesis每百万请求收费0.014美元(每个请求25 KB)，因此每GB收费0.00059美元。以每天1gb计算，每月不到0.02美元;按每天1tb计算，每月约为18美元。然而，Kinesis也收取每碎片小时0.015美元的费用。每1 MB每秒至少需要1个分片。以每天1gb计算，1个分片就足够了，因此每天将额外增加0.36美元，每月总成本为10.82美元。以每天1tb计算，您将需要至少13个碎片，每天额外增加4.68美元，每月总成本为158美元。

这些技术的语义不同，因为它们是为支持不同的场景而设计的:

• SNS/SQS:流不中的项彼此相关
• Kinesis:流是中的项彼此相关

让我们通过例子来理解其中的区别。

1. 假设我们有一个订单流，对于每个订单，我们都需要储备一些库存并安排交付。一旦完成，我们就可以安全地从流中删除项目并开始处理下一个订单。在我们开始下一个订单之前，我们已经完全完成了。
2. 同样，我们有相同的订单流，但现在我们的目标是按目的地对订单进行分组。一旦我们有10个订单到同一个地方，我们希望一起交付它们(交付优化)。现在情况不同了:当我们从流中获得一个新项时，我们无法完成它的处理;相反，我们“等待”更多的项目来实现我们的目标。此外，如果处理器进程崩溃，我们必须“恢复”状态(这样就不会丢失订单)。

一旦一个项目的处理不能与另一个项目的处理分离，我们就必须有运动语义，以便安全地处理所有的情况。

Kinesis用例

• 日志和事件数据收集
• 实时分析
• 移动数据采集
• “物联网”数据馈送

SQS用例

• 应用程序集成
• 解耦microservices
• 将任务分配给多个工作节点
• 将实时用户请求与密集的后台工作分离
• 批处理消息以供将来处理