Amazon SNS和Amazon SQS有什么区别？

Question

我不明白何时使用SNS与SQS,为什么它们总是耦合在一起？

Answer 1

SNS是分布式发布 - 订阅系统.当发布者将消息发送给SNS时,消息将被推送给订阅者.

SQS是分布式排队系统.消息不会被推送到接收者.接收方必须从SQS 轮询或提取消息.多个接收器不能同时接收消息.任何一个接收器都可以接收消息,处理并删除它.其他接收器稍后不会收到相同的消息.与SNS不同,轮询固有地在SQS中引入了一些消息传递延迟,其中消息被立即推送给订户.SNS支持多个端点,如电子邮件,短信,http端点和SQS.如果您想要未知的订户数量和类型来接收消息,则需要SNS.

您不必总是将SNS和SQS结合在一起.除了SQS,您可以让SNS向电子邮件,短信或http端点发送消息.将SNS与SQS耦合具有优势.您可能不希望外部服务与主机建立连接(防火墙可能会阻止从外部到主机的所有传入连接).你的终点可能会因为大量的消息而死亡.电子邮件和短信可能不是您快速处理邮件的选择.通过将SNS与SQS耦合,您可以按照自己的节奏接收消息.它允许客户端脱机,容忍网络和主机故障.您也可以保证交货.如果将SNS配置为将消息发送到http端点或电子邮件或SMS,则若干发送消息失败可能会导致消息被丢弃.

SQS主要用于解耦应用程序或集成应用程序.消息可以在SQS中存储很短的时间(最多14天).SNS向几个订户分发了几个消息副本.例如,假设您要将应用程序生成的数据复制到多个存储系统.您可以使用SNS和这个数据发送给多个用户,每个复制它接收到不同的存储系统(S3,您的主机,数据库硬盘等)的消息.

Answer 2

以下是一些差异

实体类型

• SQS:队列(类似于JMS)
• SNS:主题(发布/订阅系统)

消息消费

• SQS:拉动机制 - 消费者从SQS轮询和拉取消息
• SNS:推送机制 - SNS将消息推送给消费者

用例

• SQS:解耦2个应用程序并允许并行异步处理
• SNS:扇出 - 允许以多种方式处理相同消息的含义

坚持

• SQS:消息持续一段时间(可配置)持续时间没有消费者可用
• SNS:没有坚持.无论消息到达时是哪个消费者,都要获取消息并删除消息.如果没有可用的消费者,则消息将丢失.

消费者类型

• SQS:所有消费者都应该是相同的,因此以完全相同的方式处理消息
• SNS:所有消费者都(应该)以不同的方式处理消息

样品申请

• SQS:Jobs框架.将作业提交给SQS并且另一端的消费者可以异步处理作业.如果工作频率增加,则可以增加消费者的数量以进行并行处理
• SNS:图像处理.如果有人将图像上传到S3,则为该图像添加水印,创建缩略图并发送ThankYou电子邮件.在这种情况下,S3可以向SNS主题发送通知,并且可以将3个消费者附加到SNS主题.第一个水印图像,第二个创建缩略图,第三个发送ThankYou电子邮件.所有这些消息都接收相同的消息(图像URL)并进行相应的并行处理.

Answer 3

来自aws doc:

Amazon SNS允许应用程序通过"推送"机制向多个订户发送时间关键消息,从而无需定期检查或"轮询"更新.

Amazon SQS是分布式应用程序用于通过轮询模型交换消息的消息队列服务,可用于解除发送和接收组件 - 无需每个组件同时可用.

http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html

Answer 4

AWS SNS是一个发布者订阅者网络,订阅者可以订阅主题,并且只要发布者发布到该主题,就会收到消息.

AWS SQS是一种队列服务,用于将消息存储在队列中.SQS无法传递任何消息,其中需要外部服务(lambda,EC2等)来轮询SQS并从SQS获取消息.

SNS和SQS可以出于多种原因一起使用.

1. 可能存在不同类型的订户,其中一些订户需要立即传递消息,其中一些订户将要求消息持续存在,以供稍后通过轮询使用.看到这个链接.

2. " 扇出模式".这用于消息的异步处理.当消息发布到SNS时,它可以将其并行分发到多个SQS队列.在发布图像时,并行地在应用程序中加载缩略图时,这可能很棒.看到这个链接.

3. 持久存储.当要处理消息的服务不可靠时.在这种情况下,如果SNS将通知推送到服务,并且该服务不可用,则通知将丢失.因此,我们可以使用SQS作为持久存储,然后再处理它.

Answer 5

这个线程的答案有点过时了，所以我决定在上面加两分钱：

您可以将SNS视为传统主题，可以拥有多个订阅者。您可以为一个给定的SNS主题（例如Lambda和SQS）具有不同的订阅者。您还可以使用SNS开箱即用地发送SMS消息甚至电子邮件。在SNS中要考虑的一件事是一次只收到一条消息（通知），因此您无法利用批处理的优势。

另一方面，SQS只是一个队列，您可以在其中存储消息并订阅一个使用者（是的，您可以让N个使用者加入一个SQS队列，但是考虑到所有使用者，它将很快变得混乱并且难以管理。需要至少读取一次消息，因此在此用例中，最好将SNS与SQS结合使用，在这种情况下，SNS会将通知推送到N个SQS队列，并且每个队列只有一个订户来处理这些消息。自2018年6月28日起，AWS支持SQS的Lambda触发器，这意味着您无需轮询对于消息了。此外，您可以在源SQS队列上配置DLQ，以在发生故障时将消息发送到。如果成功，消息将被自动删除（这是另一个很大的改进），因此，如果您忘记手动删除消息，则不必担心会再次读取已处理的消息。我建议看看Lambda重试行为以更好地了解其工作原理。使用SQS的一大好处是可以进行批处理。每个批次最多可包含10条消息，因此，如果SQS队列中一次到达100条消息，则10个Lambda函数将启动（考虑Lambda的默认自动缩放行为），它们将处理这100条消息（保持请记住，这是一条快乐的道路，因为在实践中，更多的Lambda函数可以加速读取少于该批处理中的10条消息，但是您可以理解。但是，如果您将这100条消息发布到SNS，则会增加100个Lambda函数，从而不必要地增加了成本并用完了Lambda并发性。但是，如果您仍在运行传统服务器（例如EC2实例），则仍然需要轮询消息并手动进行管理。

您还具有FIFO SQS队列，可以保证消息的传递顺序。Lambda不支持此触发器，因此，在选择此类型的队列时，请记住，仍然需要轮询以及必须手动删除消息。

即使它们的用例有一些重叠，SQS和SNS都有自己的亮点。

在以下情况下使用SNS：

• 需要多个订阅者
• 开箱即用地发送短信/电子邮件很方便

在以下情况下使用SQS：

• 只需要一个订户
• 批处理很重要

Answer 6

以下是 AWS 上主要消息传递技术（SQS、SNS、+EventBridge）之间的主要差异。为了选择特定的AWS服务，我们应该了解该服务提供的功能以及它与其他服务的比较。

下图总结了此服务之间的主要相似点和差异。

Answer 7

简单来说，

• SNS - 使用推送机制向订阅者发送消息，不需要拉。

• SQS - 它是分布式应用程序用来通过轮询模型交换消息的消息队列服务，可用于解耦发送和接收组件。

一种常见模式是使用 SNS 将消息发布到 Amazon SQS 队列，以将消息可靠地异步发送到一个或多个系统组件。

来自Amazon SNS 常见问题的参考。