Amazon SNS和Amazon SQS有什么区别？

小开

最佳答案

SNS是一个分布式的发布订阅系统。当消息由发布者发送到SNS时，订阅者的消息是推。

SQS是分布式的排队系统。消息被没有推送给接收者。接收者必须从SQS接收投票或拉动消息。消息不能同时被多个接收者接收。任何一个接收者都可以接收消息，处理并删除它。其他接收者稍后不会收到相同的消息。轮询固有地在SQS中的消息传递中引入了一些延迟，这与SNS不同，SNS将消息立即推送给订阅者。SNS支持多个端点，例如电子邮件，SMS，HTTP终端和SQS。如果您希望未知数量和类型的订阅者接收消息，则需要SNS。

您不必总是将SNS和SQS耦合。除了SQS之外，您还可以让SNS向电子邮件、SMS或HTTP终端发送消息。将SNS与SQS耦合有很多优点。您可能不希望外部服务连接到您的主机（防火墙可能会阻止所有从外部传入的主机连接）。

您的终端可能会因为大量的消息而死亡。电子邮件和SMS可能不是您快速处理消息的选择。通过将SNS与SQS耦合，您可以按您的速度接收消息。它允许客户端即将下线，容忍网络和主机故障。您还可以实现保价信函。如果您将SNS配置为向HTTP终端或电子邮件或SMS发送消息，多次发送消息失败可能会导致消息被丢弃。

SQS主要用于解耦应用程序或集成应用程序。消息可以在SQS中存储很短的时间（最多14天）。SNS将消息的多个副本分发给多个订阅者。例如，假设你想将应用程序生成的数据复制到多个存储系统。你可以使用SNS并将此数据发送到多个订阅者，每个订阅者将收到的消息复制到不同的存储系统（S3、主机上的硬盘、数据库等）。

小开

从AWS留档：

Amazon SNS允许应用程序将时间关键消息发送到通过“推送”机制实现多个订阅者，无需定期检查或“轮询”更新。

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

扇出到Amazon SQS队列

小开

AWS SNS是一个发布者订阅者网络，订阅者可以在其中订阅主题，并且每当发布者发布到该主题时都会收到消息。

AWS SQS是一个队列服务，它将消息存储在队列中。SQS无法传递任何消息，需要外部服务（lambda、EC2等）来轮询SQS并从SQS获取消息。

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

可能有不同类型的订阅者，其中一些需要立即传递消息，其中一些需要消息以持久化，供以后通过轮询使用。请参阅此链接。
扇出模式。这是用于异步处理的消息。当消息发布到SNS时，它可以分发它并行到多个SQS队列。加载时这可能很棒并行应用程序中的缩略图，当图像被已发布。见此链接。
持久存储。当要处理消息的服务不可靠时。在这种情况下，如果SNS推送一个通知服务，并且该服务不可用，则通知将丢失。因此，我们可以使用SQS作为持久化 #36825；，然后处理它。

小开

以下是两者的比较：

实体类型

SQS：队列（类似于JMS）
SNS： Topic（发布/订阅系统）

消息消费

SQS：拉取机制-消费者从SQS轮询和拉取消息
SNS：推送机制-SNS向消费者推送消息

用例

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

持久性

SQS：如果没有可用的消费者（最多两周），消息将保留一段（可配置）时间，因此当消息添加到队列时，消费者不必启动。
SNS：无持久性。消息到达时在场的任何消费者都会收到消息并删除消息。如果没有可用的消费者，则重试几次后消息会丢失。

消费者类型

SQS：所有消费者通常是相同的，因此以完全相同的方式处理消息（每个消息由一个消费者处理一次，尽管在极少数情况下消息可能会重新发送）
SNS：消费者可能以不同的方式处理消息

示例应用程序

SQS：作业框架：将作业提交给SQS，另一端的消费者可以异步处理作业。如果作业频率增加，可以简单地增加消费者的数量来达到更好的吞吐量。
SNS：图像处理。如果有人将图像上传到S3，然后为该图像添加水印，创建缩略图并发送谢谢你电子邮件。在这种情况下，S3可以向SNS主题发布通知，并且有三个消费者收听它。第一个为图像添加水印，第二个创建缩略图，第三个发送谢谢你电子邮件。他们都收到相同的消息（图像URL）并并行进行处理。

小开

你可以将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条消息，因此如果100条消息同时到达您的SQS队列中，那么10个Lambda函数将启动（考虑到Lambda的默认自动缩放行为），它们将处理这100条消息（请记住，这是实践中的快乐路径，再增加几个Lambda函数可能会启动读取少于批次中10条消息的读取，但您明白了这一点）。然而，如果您将同样的100条消息发布到SNS，100个Lambda函数将启动，不必要地增加成本并消耗您的Lambda并发。

但是，如果您仍在运行传统服务器（例如EC2实例），您仍然需要轮询消息并手动管理它们。

您还有FIFO SQS队列，它保证消息的传递顺序。还支持SQS FIFO作为Lambda的事件源截至2019年11月

尽管它们的用例有一些重叠，但SQS和SNS都有自己的焦点。

使用SNS如果：

多个订阅者是一个要求
开箱即用发送SMS/E-mail很方便

使用SQS如果：

只需要一个订阅者
批处理很重要

小开

简单来说，

SNS-使用推送机制向订阅者发送消息，无需拉取。
SQS-它是分布式应用程序用来通过轮询模型交换消息的消息队列服务，可用于解耦发送和接收组件。

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

引用自亚马逊SNS常见问题。

小开

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

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

小开

耦合SQS和SNS的一个原因是数据处理管道。

假设您正在生成三种产品，并且产品B&C都源自相同的中间产品A。对于每种产品（即管道的每个部分），您设置：

计算资源（可能是lambda函数、虚拟机集群或自动缩放kubernetes作业）来生成产品。
一个队列（描述需要执行的工作单元），用于跨计算资源对工作进行分区（以便每个工作单元只处理一次，但单独的工作单元可以并行和异步地单独处理）。
新闻提要（宣布已经产生的输出）。

然后安排，使B&C的输入队列都订阅A的输出公告。

这使得管道在基础设施层面上是模块化的。管道的不同阶段可以利用不同的硬件资源，而不是让一个单一的服务器应用程序一起生成所有三种产品（例如，也许阶段B是非常内存密集型的，但其他两个阶段可以使用更便宜的硬件/服务执行）。这也使得在不中断其他产品交付的情况下更容易迭代一个管道段的开发。