文章目录

    • 一、前言
    • 二、Amazon SNS 服务（Amazon Simple Notification Service）
    • 三、Amazon SQS 服务（Amazon Simple Queue Service）
    • 四、SNS 与 SQS 的区别（本文重点）
      • 4.1 基于推送和轮询区别
      • 4.2 消费者数量对应关系不同
      • 4.3 消费者类型的不同
      • 4.4 持久性不同
      • 4.5 可靠性重试策略不同
      • 4.6 批处理数量不同
    • 五、如何选择 SNS 与 SQS 服务
    • 六、SNS 与 SQS 服务使用案例
      • 6.1 社交网络服务云监控警报（SNS 案例）
      • 6.2 处理选票案例（SQS 案例）
      • 6.3 SNS 和 SQS 的组合 – 扇出模式
    • 七、文末总结

一、前言

AWS 提供许多出色的消息传递服务。他们最著名的两项服务是 Amazon Simple Notification Service (SNS) 和 Amazon Simple Queue Service (SQS)。虽然两者的使用方式非常相似，但它们是完全不同的服务。

这篇博文将向您解释相同点、不同点以及如何选择哪种服务。最后，我将向您展示一些示例用例和一种常见的事件驱动模式。

二、Amazon SNS 服务（Amazon Simple Notification Service）

Amazon 的 SNS 是一项完全托管的发布和订阅服务。发布者向某个主题发送消息，并且许多消费者/订阅者订阅了该主题。这种关系是多对多的。一个主题可以有多个发布者和多个订阅者。

SNS 在发送方式上有所区别。它可以是应用程序到应用程序A2A或应用程序到个人A2P。

  • 应用程序到应用程序（Application to Application A2A）目的地是：

    • AWS Lambda
    • 亚马逊SQS
    • 亚马逊 Kinesis Data Firehose
    • AWS 事件分支管道
    • HTTP 端点

  • 应用到个人（Application to Person A2P）目的地是：

    • 短信
    • 电子邮件
    • 应用内通知
    • AWS 聊天机器人
    • 寻呼机任务

SNS 性能超强。消息将在几毫秒内发布。

一种常见的模式是扇出模式（fan-out pattern），它允许将一个事件扇出到 AWS 内的各个订阅者。稍后我将在用例部分更详细地介绍该模式。

SNS 允许标准主题或 FIFO 主题。 FIFO 主题有消息排序，而标准主题则没有消息排列。对于 FIFO 主题，有更严格的限制！

三、Amazon SQS 服务（Amazon Simple Queue Service）

AWS SQS 是一种完全托管的分布式排队服务。 SQS 是基于轮询的，而不是基于推送的。即使它通常看起来像是一个基于推送的系统，但事实并非如此。 Amazon SQS 通常用于将系统相互解耦并启用异步工作负载。

Amazon SQS 的主要模式是让生产者将消息发送到队列。消息在队列中保留一段定义的时间（默认为 4 天，最多 14 天）。消费者可以通过检查队列是否有新消息来按照自己的时间表获取消息。

如果消费者处理消息，如果成功，该消息将被删除。否则，它也可能被其他消费者捡起。

SQS 通过其重新驱动策略提供了许多重试消息的功能。您可以定义重试次数和死信队列，以防消息失败。 死信队列 (DLQ) 用于处理有错误的消息。如果消息无法处理，它们将被发送到 DLQ，以通知应用程序开发人员有关问题的信息，并可选择保存消息以在原始队列中重播。

在 AWS 中，DLQ 指的是“Dead Letter Queue”（死信队列）。它是一种用于处理消息系统中处理失败消息的机制。当消息因某种原因无法被消费者成功处理时，这些失败的消息通常会被发送到死信队列中。这种机制通常用于消息队列服务（比如 Amazon SQS – Simple Queue Service 或者 Amazon SNS – Simple Notification Service）中，以确保失败的消息不会丢失，并且可以被进一步分析或重新处理。

死信队列有助于识别处理失败的消息，可以对失败的消息进行分析、排查原因，并采取适当的措施，比如重新处理消息或者通知相关人员进行干预。

SQS 具有多对一的关系。您可以将消息从许多不同的生产者发送到队列，但只能定义一个消费者。消费者是另一个应用程序，通常是一些计算实例，例如 Lambda、EC2 或 Fargate。

有两种不同类型的队列：标准队列和先进先出（FIFO）队列。后者将使消息保持有序。

四、SNS 与 SQS 的区别（本文重点）

我们知道这两种服务都以某种方式处理消息。这两种服务都可以实现更好的解耦。后端API和后台逻辑的执行是松耦合的，不再有联系。

但也存在显着差异。让我们来看看所有这些对比表格

SNSSQS
推送/轮询的差异推送轮询
消费者数量对应关系多对多多对一
消费者类型A2A 或 A2PA2A
持久性✘✔
可靠性/重试✘✔
批处理✘✔

下面对于 SNS 与 SQS 的区别进行详细说明一下

4.1 基于推送和轮询区别

主要区别在于服务的基础。 SQS 是基于轮询的，SNS 是基于推送的服务。

这意味着 SNS 只是将所有消息转发给订阅的消费者，而 SQS 确实将消息保存在队列中并等待它们被获取。这是各个方面的显着差异。例如，SQS 架构中的延迟会稍高一些，因为仍然需要考虑轮询。另一方面，SQS 的持久性和可靠性要好得多，因为消息会在短时间内正确保存。

4.2 消费者数量对应关系不同

第二个区别是关系的类型。两种服务都可以接收来自不同生产者的消息。这意味着这两项服务具有多对x关系。

主要区别在于 SNS 可以有很多订阅者，而 SQS 只能有一个消费者。

SNS 订阅者的当前限制为每个主题 12,500,000 名订阅者。可以说是非常多！这意味着您可以有很多消费者来处理您的消息。

另一方面，SQS 只能有一个消费者。该消费者正在处理该消息，然后删除该消息。

4.3 消费者类型的不同

SNS 将消息发送到应用程序或直接发送到个人，或两者都有。这意味着它支持各种不同的消费者类型。

另一方面，SQS 消息通常会使用 SQS API 来获取。因此每个支持 AWS SDK 的客户端都可以使用它。通常，队列中的消息将从 AWS Lambda 获取，因为存在与 SQS 和 Lambda 的本机集成。但也可以使用 SQS API 简单地拾取和删除消息。也可以在本地 PC 上进行操作。

4.4 持久性不同

SQS 中的消息将保存一段时间。这称为保留期。保留期限可以在 1 分钟到 14 天之间，默认值为 4 天。如果在该时间范围内未收到该消息，该消息将被自动删除。

然而，在SNS中，不存在持久性。无法保证消息一定会送达。如果消费者不可用，则消息将不会被传递。

这可以对可靠性产生很大的影响。例如，如果消费者在 SNS 中不可用，则消息将不会被传递。或者，如果消费者没有成功结束，消息就会消失。 SQS 增加了很多可靠性。扇出模式可用于将两者结合起来，但稍后会详细介绍该部分。

4.5 可靠性重试策略不同

SQS 能够添加重新驱动策略。此策略定义在将失败的消息移至死信队列（DLQ）之前应重试多少次。 DLQ 处理失败的消息。例如，可以将失败的消息保存在存储桶中并通知开发人员。

当客户端失败时，SNS 不提供重试。如果消费者不可用或消费者无法处理消息（例如，推送通知无法通过），则无法重复该消息。这是由于 SNS 的异步特性造成的。

4.6 批处理数量不同

SQS 允许你批量将多条消息合并为一条消息。您可以定义参数batch_size。对于标准队列，批量大小最多可以为 10,000 条记录；对于 FIFO 队列，批量大小最多可以为 10 条。

SNS 一次只能处理一条消息，因此无法进行批处理。

冷知识（12/29/2023 23:40 更新）无论是SNS，还是 SQS 都有消息大小限制，消息体大小不能超过 256KB。
标准队列（Standard Queue）：

  • 最大消息大小为 256KB（以二进制计量），其中包括消息体、属性和标签。

FIFO 队列：

  • 最大消息大小为 256KB（以二进制计量），与标准队列相同。 此外，FIFO 队列还有 5 条限制条件：发送者 ID、消息分组
  • ID、消息去重 ID、消息属性和延迟发送消息属性的总大小不得超过 256KB。

五、如何选择 SNS 与 SQS 服务

如果你是架构师，在设计架构的时候，对于 SNS 与 SQS 服务应该如何选择呢，或者说，我什么时候选择 SNS，什么时候选择 SQS。

下面是根据自身经验，总结的一些一般建议：

如果出现以下情况，请使用 SNS：

  • 你有很多订阅者
  • 你需要向消费者发送短信、电子邮件或应用程序通知类型
  • 你想要使用扇出模式同时向许多订阅者发送消息（稍后会详细介绍）

如果出现以下情况，请使用 SQS：

  • 你只需要一名订阅者
  • 持久性和错误处理非常重要（每条消息都需要传递）
  • 你需要批量处理你的请求
  • 你只想解耦应用程序并启用异步后台处理

六、SNS 与 SQS 服务使用案例

为了方便大家理解，这里列举几个SNS 与 SQS 服务使用案例。

6.1 社交网络服务云监控警报（SNS 案例）

例如一个警报将会被触发，你想要向 10 个不同的电子邮件地址发送消息，并向一些手机发送短信。持久性、批处理和重试并不重要。这种场景非常可能在 SAA/SAP 认证考试中提出来，所以你要知道使用什么服务。

6.2 处理选票案例（SQS 案例）

你的应用程序以同步方式执行所有任务，并且你的用户需要等待 API 返回。通过添加 SQS 队列，你可以运行后台任务并解耦整个应用程序。 你需要同时处理大量消息。 SQS 可以通过批量处理所有消息来解决这个问题。

你主持了一场创业秀，同时获得了大量的选票。你需要处理这些投票。让你的 API 处理所有这些事情是不可行的，并且你不希望您的用户等待处理它们所需的时间。

你可以使用 SQS 来实现这一点。当用户投票时，你的 API 会向 SQS 发送一条消息。你的 API 将向最终用户返回 200 OK，最终用户会获得超快的响应。

实际的业务逻辑是解耦的。 SQS 和 Lambda 将处理剩下的事情。在这种情况下，许多消息将被批处理在一起，并且将生成许多 lambda 函数。这就是可扩展性的例子。

6.3 SNS 和 SQS 的组合 – 扇出模式

到目前为止，在本文中，我们已经将 SNS 和 SQS 视为两种不同的服务。有一种常见的模式将这两种服务结合在一起。这称为扇出模式。

扇出模式描述了发布到 SNS 的消息将同时发送到多个端点的场景。对于这样的模式，一条消息可能会触发多次执行。这允许异步处理。

这里列举一个社交媒体网络的案例：

假设你现在在一个论坛媒体发送帖子，对于发布的每个帖子，可能需要采取多项操作的地方：

  • SQS 队列 1：将帖子翻译成不同语言
  • SQS 队列 2：将帖子转换为音频
  • SQS 队列 3：更新用户统计信息（帖子数量）
  • 电子邮件：通知关注者有新帖子
  • 应用消息通知：通知关注者有关新帖子的信息

七、文末总结

本文向您介绍了 AWS 服务 Amazon Simple Queue Service (SQS) 和 Amazon Simple Notification Service (SNS)。这些服务构建了许多分布式和解耦应用程序的基础。

SNS 是多对多的发布/订阅模型，适合多订阅者和通知类消息。相反，SQS 是基于队列的多对一模型，重视消息持久性和可靠性。文中提供了选择服务的指南，包括适用场景和使用案例。文章最后介绍了扇出模式，即如何结合使用 SNS 和 SQS，以实现消息同时发送到多个端点。

该服务已存在多年，是 AWS 的主要支柱之一。 使用这些服务构建可靠且高性能的应用程序至关重要。

[ 本文作者 ] bluetata[ 原文链接 ] https://bluetata.blog.csdn.net/article/details/135293801[ 最后更新 ] 12/29/2023 18:18[ 版权声明 ] 如果您在非 CSDN 网站内看到这一行，说明网络爬虫可能在本人还没有完整发布的时候就抓走了我的文章，可能导致内容不完整，请去上述的原文链接查看原文。