[ 云计算 | AWS ] 对比分析:Amazon SNS 与 SQS 消息服务的异同与选择

2024-01-02 22:28

本文主要是介绍[ 云计算 | AWS ] 对比分析:Amazon SNS 与 SQS 消息服务的异同与选择,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在这里插入图片描述

文章目录

    • 一、前言
    • 二、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 网站内看到这一行,
说明网络爬虫可能在本人还没有完整发布的时候就抓走了我的文章,
可能导致内容不完整,请去上述的原文链接查看原文。

这篇关于[ 云计算 | AWS ] 对比分析:Amazon SNS 与 SQS 消息服务的异同与选择的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/563811

相关文章

Go标准库常见错误分析和解决办法

《Go标准库常见错误分析和解决办法》Go语言的标准库为开发者提供了丰富且高效的工具,涵盖了从网络编程到文件操作等各个方面,然而,标准库虽好,使用不当却可能适得其反,正所谓工欲善其事,必先利其器,本文将... 目录1. 使用了错误的time.Duration2. time.After导致的内存泄漏3. jsO

SpringKafka消息发布之KafkaTemplate与事务支持功能

《SpringKafka消息发布之KafkaTemplate与事务支持功能》通过本文介绍的基本用法、序列化选项、事务支持、错误处理和性能优化技术,开发者可以构建高效可靠的Kafka消息发布系统,事务支... 目录引言一、KafkaTemplate基础二、消息序列化三、事务支持机制四、错误处理与重试五、性能优

SpringIntegration消息路由之Router的条件路由与过滤功能

《SpringIntegration消息路由之Router的条件路由与过滤功能》本文详细介绍了Router的基础概念、条件路由实现、基于消息头的路由、动态路由与路由表、消息过滤与选择性路由以及错误处理... 目录引言一、Router基础概念二、条件路由实现三、基于消息头的路由四、动态路由与路由表五、消息过滤

Spring事务中@Transactional注解不生效的原因分析与解决

《Spring事务中@Transactional注解不生效的原因分析与解决》在Spring框架中,@Transactional注解是管理数据库事务的核心方式,本文将深入分析事务自调用的底层原理,解释为... 目录1. 引言2. 事务自调用问题重现2.1 示例代码2.2 问题现象3. 为什么事务自调用会失效3

找不到Anaconda prompt终端的原因分析及解决方案

《找不到Anacondaprompt终端的原因分析及解决方案》因为anaconda还没有初始化,在安装anaconda的过程中,有一行是否要添加anaconda到菜单目录中,由于没有勾选,导致没有菜... 目录问题原因问http://www.chinasem.cn题解决安装了 Anaconda 却找不到 An

Spring定时任务只执行一次的原因分析与解决方案

《Spring定时任务只执行一次的原因分析与解决方案》在使用Spring的@Scheduled定时任务时,你是否遇到过任务只执行一次,后续不再触发的情况?这种情况可能由多种原因导致,如未启用调度、线程... 目录1. 问题背景2. Spring定时任务的基本用法3. 为什么定时任务只执行一次?3.1 未启用

Python实现Microsoft Office自动化的几种方式及对比详解

《Python实现MicrosoftOffice自动化的几种方式及对比详解》办公自动化是指利用现代化设备和技术,代替办公人员的部分手动或重复性业务活动,优质而高效地处理办公事务,实现对信息的高效利用... 目录一、基于COM接口的自动化(pywin32)二、独立文件操作库1. Word处理(python-d

Linux上设置Ollama服务配置(常用环境变量)

《Linux上设置Ollama服务配置(常用环境变量)》本文主要介绍了Linux上设置Ollama服务配置(常用环境变量),Ollama提供了多种环境变量供配置,如调试模式、模型目录等,下面就来介绍一... 目录在 linux 上设置环境变量配置 OllamPOgxSRJfa手动安装安装特定版本查看日志在

Java常用注解扩展对比举例详解

《Java常用注解扩展对比举例详解》:本文主要介绍Java常用注解扩展对比的相关资料,提供了丰富的代码示例,并总结了最佳实践建议,帮助开发者更好地理解和应用这些注解,需要的朋友可以参考下... 目录一、@Controller 与 @RestController 对比二、使用 @Data 与 不使用 @Dat

python中字符串拼接的几种方法及优缺点对比详解

《python中字符串拼接的几种方法及优缺点对比详解》在Python中,字符串拼接是常见的操作,Python提供了多种方法来拼接字符串,每种方法有其优缺点和适用场景,以下是几种常见的字符串拼接方法,需... 目录1. 使用 + 运算符示例:优缺点:2. 使用&nbsjsp;join() 方法示例:优缺点:3