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：作业框架：作业提交给SQS，另一端的消费者可以异步处理作业。如果工作频率增加，可以简单地增加消费者的数量以实现更好的吞吐量。
• SNS：图像处理。如果有人将图像上传到S3，则为该图像添加水印，创建缩略图并发送感谢信。在这种情况下，S3可以向SNS主题发布通知，其中3个消费者正在收听它。第一个水印图像，第二个创建缩略图，第三个发送谢谢你的电子邮件。所有这些消息都会收到相同的消息（图像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. 可能会有不同类型的订阅者需要 即时传递消息，其中一些消息需要消息 坚持，以后通过民意调查使用。请参阅此link。

2. ＆＃34; 扇出模式。＆＃34;这是用于异步处理的 消息。当消息发布到SNS时，它可以分发它 多个SQS队列并行。加载时这可能很棒 当图像存在时，应用程序中的缩略图并行显示 出版。见link。

3. 持久存储空间。当要处理消息的服务不可靠时。在这种情况下，如果SNS推动了 通知服务，该服务不可用，然后 通知将丢失。因此我们可以使用SQS作为持久性 然后存储，然后处理它。

Answer 5

该线程的答案有些过时了，因此我决定在其中加两分钱：

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

另一方面，

SQS 只是一个队列，您可以在其中存储消息并订阅一个使用者（是的，您可以让N个使用者进入一个SQS队列，但这会很混乱考虑到所有使用者至少需要阅读一次消息，因此管理起来很快且更困难。因此，在这种用例下，SNS与SQS结合使用会更好，因为SNS会将通知推送到N个SQS队列，每个队列只有一个订户（仅限））来处理这些消息。截至2018年6月28日，AWS Supports Lambda Triggers for SQS，这意味着您不再需要轮询来接收消息。此外，您可以在源SQS队列上配置DLQ，以在发生故障时将消息发送到。如果成功，消息将被自动删除（这是另一个很大的改进），因此，如果您忘记手动删除消息，则不必担心会再次读取已处理的消息。建议您看一下Lambda Retry Behaviour，以更好地了解其工作原理。使用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

简单来说， SNS-使用推送机制向订阅者发送消息，无需拉取。 SQS-这是一种消息队列服务，分布式应用程序使用该消息队列服务通过轮询模型交换消息，并且可以用于分离发送和接收组件。

一个人可以将上述两种方法结合起来，并像这样实现：

SNS->将消息发布到-> SQS->异步发送到许多系统。

Answer 7

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

下图总结了此服务之间的主要异同。