631

我什么时候会使用 SNS 和 SQS，为什么它们总是耦合在一起？

4

8 回答 8

888

SNS是一个分布式发布订阅系统。消息在发布者发送到 SNS 时被推送给订阅者。

SQS是分布式排队系统。消息不会推送给接收者。接收者必须从SQS轮询或拉取消息。多个接收者不能同时接收消息。任何一个接收者都可以接收、处理和删除消息。其他接收者稍后不会收到相同的消息。与 SNS 不同，轮询在 SQS 中的消息传递中固有地引入了一些延迟，后者将消息立即推送给订阅者。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、主机上的硬盘、数据库等）。

于 2012-12-03T22:14:26.627 回答
356

这是两者的比较：

实体类型

  • SQS：队列（类似于 JMS）
  • SNS：主题（Pub/Sub 系统）

消息消费

  • SQS: Pull Mechanism - 消费者从 SQS 轮询和拉取消息
  • SNS: Push Mechanism - SNS 向消费者推送消息

用例

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

持久性

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

消费者类型

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

示例应用程序

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

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

另一方面，SQS只不过是一个队列，您可以在其中存储消息并订阅一个消费者（是的，您可以让 N 个消费者加入一个 SQS 队列，但是考虑到所有消费者都会很快变得混乱，并且更难管理需要至少读取一次消息，因此对于此用例，将 SNS 与 SQS 结合使用会更好，其中 SNS 会将通知推送到 N 个 SQS 队列，并且每个队列只有一个订阅者）来处理这些消息。自 2018 年 6 月 28 日起，AWS 支持 SQS 的 Lambda 触发器，这意味着您不再需要轮询消息。

此外，您可以在源 SQS 队列上配置 DLQ，以便在发生故障时向其发送消息。如果成功，消息会被自动删除（这是另一个很大的改进），因此您不必担心已经处理的消息会被再次读取，以防您忘记手动删除它们。我建议查看Lambda Retry Behavior以更好地了解它的工作原理。

使用 SQS 的一大好处是它支持批处理。每个批次最多可以包含 10 条消息，因此如果 100 条消息同时到达您的 SQS 队列，那么 10 个 Lambda 函数将启动（考虑 Lambda 的默认自动扩展行为）并且它们将处理这 100 条消息（保留在请注意，这是实践中的快乐路径，更多的 Lambda 函数可能会启动读取少于批处理中的 10 条消息，但您明白了）。但是，如果您将这 100 条相同的消息发布到 SNS，则会启动 100 个 Lambda 函数，从而不必要地增加成本并耗尽您的 Lambda 并发性。

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

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

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

在以下情况下使用SNS：

  • 多个订阅者是一项要求
  • 开箱即用发送短信/电子邮件很方便

在以下情况下使用SQS：

  • 只需要一个订阅者
  • 分批很重要
于 2019-03-20T13:24:48.017 回答
50

AWS SNS是一个发布者订阅者网络，订阅者可以订阅主题，并在发布者发布到该主题时接收消息。

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

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

  1. 可能有不同类型的订阅者，其中有些需要立即传递消息，有些则需要保留消息，以供以后通过轮询使用。请参阅此链接。

  2. “扇出模式”。这是用于消息的异步处理。当消息发布到 SNS 时，它可以将其并行分发到多个 SQS 队列。在发布图像时，在应用程序中并行加载缩略图时，这可能非常有用。请参阅此链接。

  3. 持久存储。当要处理消息的服务不可靠时。在这种情况下，如果 SNS 向 Service 推送通知，而该服务不可用，则通知将丢失。因此，我们可以将 SQS 用作持久存储，然后再对其进行处理。

于 2018-04-18T05:36:02.983 回答
34

从 AWS 文档：

Amazon SNS 允许应用程序通过“推送”机制向多个订阅者发送时间紧迫的消息，从而无需定期检查或“轮询”更新。

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

扇出到 Amazon SQS 队列

于 2014-03-12T04:31:32.847 回答
8

简单来说，

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

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

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

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

于 2019-05-27T20:13:45.003 回答
8

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

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

在此处输入图像描述

于 2021-04-05T05:00:55.373 回答
0

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

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

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

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

这使得管道在基础设施级别上模块化。与其拥有一个同时生成所有三个产品的单一服务器应用程序，流水线的不同阶段可以利用不同的硬件资源（例如，阶段 B 可能非常占用内存，但其他两个阶段可以使用更便宜的硬件/服务来执行） . 这也使得在不中断其他产品交付的情况下迭代开发一个管道段变得更加容易。

于 2021-12-22T09:36:12.183 回答