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

Question

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

Apo*_*orv 146 amazon-sqs amazon-web-services amazon-kinesis

我有一个用例,会有数据流来,我不能以相同的速度消耗它,需要一个缓冲区.这可以使用SNS-SQS队列来解决.我开始知道Kinesis解决了同样的目的,那有什么区别？为什么我更喜欢(或不应该更喜欢)Kinesis？

Answer 1

Roe*_*rel 73

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

在研究了这个问题一段时间后,考虑到同样的问题,我发现SQS(带有SNS)是大多数用例的首选,除非消息的顺序对你很重要(SQS不保证消息上的FIFO).

Kinesis有两个主要优点(1)您可以从多个应用程序中读取相同的消息;(2)您可以在需要时重新阅读消息.

通过将SNS用作SQS的扇出,可以实现这两个优点.这意味着消息的生产者只向SNS发送一条消息,然后SNS将消息扇出到多个SQS,每个消费者应用程序一个.通过这种方式,您可以拥有所需的消费者,而无需考虑分割容量.

此外,我们又添加了一个订阅SNS的SQS,该SQ将保留14天的消息.在正常情况下,没有人从这个SQS读取,但是如果出现让我们想要倒回数据的错误,我们可以轻松地读取来自此SQS的所有消息并将它们重新发送到SNS.虽然Kinesis仅提供7天的保留期.

总之,SNS + SQS更容易并提供大多数功能.IMO你需要一个非常强大的案例来选择Kinesis.

最近,AWS发布了SQS FIFO [http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html],它可以提供消息的时间顺序. (28认同)
超级评论 - 可能不会在"SNS将消息拆分为多个SQS"中使用"split"这个词,因为它不会将消息分解成碎片,而是将其复制到多个目的地. (4认同)
仅供参考:您可以让Kinesis保留最多7天. (2认同)
由于每个分片/秒的读取器数量受到限制，Kinesis不适合用于扇出（发布-订阅）用例。尽管与原始查询无关，但任何依赖Kinesis扩展至n读者的人都应考虑这一事实。https://forums.aws.amazon.com/message.jspa?messageID=760351 (2认同)
@alexP_Keaton - 首先我要说的是这个答案是 2.5 年前的，我想从那时起 Kinesis 中的很多事情都发生了变化。当时，Kinesis 的痛苦在于它存储数据长达 48 小时，而 SQS 只能存储 14 天。在 Kinesis 中，您会在客户端上产生开销，并使用 DynamoDB 来处理读取的定位。最重要的是，在 Kinesis 中，您必须提前配置分片，这会限制您的读取速度，而在 SQS 中，您可以不假思索地上下调整速度。 (2认同)
Kinesis的订单保证是按分片而不是按流的。一旦您拥有多个分片，整个流将无法保证有序。对于SQS队列，当吞吐量相对较低时，几乎是FIFO。仅当您的吞吐量提高时，才遵循该顺序。这是关于经典SQS队列，而不是FIFO队列。 (2认同)

Answer 2

E.J*_*nan 52

从表面上看,它们模糊地相似,但您的用例将决定哪种工具是合适的.IMO,如果你可以接受SQS那么你应该 - 如果它能做你想做的事情,它会更简单,更便宜,但这里有一个更好的解释,从AWS FAQ中给出了两个工具的适当用例的例子.帮你决定:

常见问题解答

仅供参考http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-subscribe-queue-sns-topic.html SQS FIFO不适用于SNS (7认同)

Answer 3

kar*_*tik 51

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

其次,Kinesis使用可以由特定EC2实例处理的分区密钥为不同分片选择性路由数据记录提供路由功能,并且可以启用微批量计算{Counting&aggregation}.

使用任何AWS软件都很容易,但SQS最容易.使用Kinesis时,需要提前提供足够的分片,动态增加分片数量以管理峰值负载,并减少管理所需的成本.它在Kinesis中很痛苦,SQS不需要这样的东西.SQS具有无限可扩展性.

关于你对SQS的解释.通过在它们之前设置SNS,您可以轻松地将相同的消息发送到多个SQS. (11认同)
app - > sns主题---> sqs1,sqs2,sqs3 ......？ (7认同)
是的,我指的是这种方法. (4认同)

Answer 4

Kon*_*ger 40

这些技术的语义不同,因为它们旨在支持不同的场景:

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

让我们通过例子来理解差异.

假设我们有一个订单流,我们需要为每个订单预留一些库存并安排交货.完成后,我们可以安全地从流中删除该项目并开始处理下一个订单.我们完全完成之前,我们开始下一个与以前的订单.
同样,我们拥有相同的订单流,但现在我们的目标是按目的地对订单进行分组.一旦我们有10个订单到同一个地方,我们希望将它们一起交付(交付优化).现在的情况有所不同:当我们从流中获得一个新项目时,我们无法完成处理; 相反,我们"等待"更多物品来实现我们的目标.此外,如果处理器进程崩溃,我们必须"恢复"状态(因此不会丢失任何订单).

一旦一个项目的处理无法与处理另一个项目分开,我们必须具有Kinesis语义,以便安全地处理所有案例.

@AndyDufresne：这很好地涵盖了顺序很重要的场景。在上述情况 (1) 中，您可能希望“按顺序”处理订单。因此，如果缺货，后续订单将被拒绝或延迟。FIFO 语义并没有解决核心相对性（分组）问题。 (2认同)

Answer 5

Mat*_*rry 30

对我来说最大的好处是Kinesis是一个可重放的队列,而SQS则不是.因此,您可以让多个消费者使用相同的Kinesis消息(或者在不同时间使用相同的消费者),使用SQS,一旦消息被激活,它就会从该队列消失.因此,SQS更适合工作队列.

也许这是一个新事物@farhad，我7年前回答过这个问题。实施了此类删除策略的侦听器是否会再次获取相同的消息，或者是否允许您跳过消息？无论如何，SQS 的通常做法仍然更多的是工作队列，尽管可以将其滥用于其他用途 (3认同)

Answer 6

小智 29

摘自AWS文档:

对于具有以下类似要求的用例,我们建议使用Amazon Kinesis Streams:

将相关记录路由到同一记录处理器(如流式MapReduce).例如,当给定密钥的所有记录都路由到同一记录处理器时,计数和聚合更简单.

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

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

能够在几小时后以相同的顺序使用记录.例如,您有一个计费应用程序和一个审计应用程序,它运行在计费应用程序后面几个小时.由于Amazon Kinesis Streams最多可存储7天的数据,因此您可以在结算应用程序后最多7天运行审计应用程序.

对于具有以下类似要求的用例,我们建议使用Amazon SQS:

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

个人消息延迟.例如,您有一个作业队列,需要延迟安排单个作业.使用Amazon SQS,您可以将单个邮件配置为最多延迟15分钟.

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

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

Answer 7

Den*_*kem 15

另一件事:Kinesis可以触发Lambda,而SQS则不能.因此,使用SQS,您必须提供EC2实例来处理SQS消息(如果失败则处理它),或者您必须有一个预定的Lambda(不会向上或向下扩展 - 您每分钟只能获得一个) .

Lambda现在支持SQS作为触发器! (14认同)
我不确定我是否同意这种分歧;] - 你可以安排一个lambda /分钟,这将限制你批量处理到达该间隔的消息.Kinesis允许您立即阅读消息.或者是我误解的东西？ (5认同)

Answer 8

Sha*_*dan 10

Kinesis 用例

\n\n

日志和事件数据收集
实时分析
移动数据采集
\xe2\x80\x9c 物联网\xe2\x80\x9d 数据源

\n\n

SQS 用例

\n\n

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

\n

Kinesis 不能做您提到的 SQS 能做的所有事情吗？ (4认同)

Answer 9

Joh*_*nis 9

定价模式不同,因此根据您的使用情况,一个或另一个可能更便宜.使用最简单的情况(不包括SNS):

每条消息的SQS费用(每个64 KB计为一个请求).
每小时每个分片的Kinesis费用(1个分片最多可处理1000条消息或1 MB /秒)以及您输入的数据量(每25 KB).

插入当前价格而不考虑免费套餐,如果您以最大邮件大小每天发送1 GB邮件,Kinesis的费用将远高于SQS(Kinesis每月10.82美元,SQS每月0.20美元) .但如果你每天送1 TB,Kinesis便宜一些(每月158美元,而SQS每月201美元).

详细信息:SQS每百万个请求收费0.40美元(每个64 KB),因此每GB为0.00655美元.每天1 GB,每月不到0.20美元; 每天1 TB,每月略高于201美元.

Kinesis收取每百万请求0.014美元(每个25 KB),因此每GB 0.00059美元.每天1 GB,每月不到0.02美元; 每天1 TB,每月约18美元.但是,Kinesis每小时收费0.015美元.每秒每MB需要至少1个分片.每天1 GB,1个碎片将是充足的,因此每天将增加0.36美元,总费用为每月10.82美元.每天1 TB,您将需要至少13个碎片,每天再增加4.68美元,每月总费用为158美元.

Answer 10

小智 8

Kinesis在流数据的典型map-reduce场景中解决了map部分的问题.虽然SQS没有确定这一点.如果您有需要在密钥上聚合的流数据,kinesis会确保该密钥的所有数据都转到特定分片,并且可以在单个主机上使用该分片,这使得与SQS相比,密钥上的聚合更容易

Answer 11

小智 5

我还要再添加一个没有人提及的东西-SQS的价格要贵几个数量级。

你确定吗？根据我的计算，Kinesis的价格要贵得多，但是我从来没有使用过Amazon Simple Price Calculator的才华。 (3认同)
假设您每天进行扇出操作，表示 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 美元/天。 (3认同)
我很想知道为什么这个线程中的成本如此悬殊。 (3认同)
SQS 定价的一个问题是，规定的每 100 万个请求的成本率并不是实际的消息。这是 API 操作，其中 1 个请求 = 1 个 API 操作。为了处理单个“消息”，需要执行至少 3 个 API 操作：1 个发送 + 1 个接收 + 1 个删除。其他 SQS 功能（例如更改可见性）将引发更多 API 操作。这种意想不到的乘数非常令人讨厌，对于大型数据集（例如每月处理 1 亿条消息），SQS 的成本通常比 Kinesis Streams 贵 2-10 倍。 (3认同)

归档时间：	10 年，12 月前
查看次数：	60890 次
最近记录：	6 年前