什么是 Amazon SNS？
Amazon Simple Notification Service（SNS）是一项全托管的消息服务，支持应用到应用（A2A）与应用到个人（A2P）通信。它专为实时通知而设计，能够高效、可扩展地将消息传递给应用与终端用户。
与 SQS 类似，Amazon SNS 也通过允许用户创建 死信队列 来存储无法处理的消息，以实现消息持久性。
Amazon SNS 采用发布/订阅（pub/sub）消息模型，由三部分构成：
- 发布者： 创建并将消息发送到 SNS 主题的系统。
- 主题： 用作访问点，将消息分发至多个终端。
- 订阅者： 也称消费者，是从主题接收消息的终端。
SNS 消息模型架构示意图。图片来源：AWS
SNS 具有很高的性能，可同时向多个订阅者发送消息。对于 A2A 通信，SNS 可将消息投递至 AWS Lambda、Amazon Kinesis Firehose，甚至 Amazon SQS。对于 A2P 通信，SNS 可通过短信、电子邮件或推送通知直接向用户发送消息。
如果您希望系统掌握 AWS 并整合其多项服务以创建最佳解决方案，建议学习 AWS Cloud Technology and Services 课程。
包括告警系统、扇出架构与实时通知在内的特性，共同造就了 Amazon SNS 的高健壮性与高可靠性。凭借高消息吞吐量以及同时支持 A2A 与 A2P 通信的能力，SNS 常常是事件驱动架构中的关键组成部分。
SQS 与 SNS 的核心差异
在二者之间进行选择，前提是深入理解它们的差异。本节概述二者的主要区分标准。
推送 vs. 轮询
Amazon SQS 使用轮询机制，消费者会定期轮询队列以检查是否有新消息。
Amazon SNS 则是基于推送的系统，一旦消息发布到主题，便会自动将其推送到订阅者。
接收方类型
Amazon SQS 仅支持 A2A 通信，可将消息发送至其他 AWS 服务，如 AWS EC2、AWS Lambda、AWS RDS 与 AWS Redshift。
Amazon SNS 支持 A2A 与 A2P 通信，可将消息发送至 AWS 服务（如 AWS S3、AWS EC2）以及用户联系方式（如短信与电子邮件）作为订阅者。
消息保留
Amazon SQS 最长可将消息存储 14 天，给消费者足够的处理时间。相对地，Amazon SNS 不会保留消息，而是在消息发布后立即将其投递给订阅者。
消息投递模型
Amazon SQS 采用一对一模型，即每条消息仅由一个消费者处理。即使多个消费者同时轮询，给定消息也只会被其中一个获取。在该消费者处理消息期间，SQS 会利用 可见性超时 功能，使该消息对其他消费者不可见。
Amazon SNS 支持 扇出模式，即同一条主题消息可同时发送给所有订阅者，各订阅者独立处理所接收到的消息。
批处理
Amazon SQS 允许用户对消息进行批处理，即按批次向消费者发送消息。批大小可在 AWS 中配置。
Amazon SNS 不支持批处理，一次只能处理一条消息。
下表对这些关键差异进行了汇总：
|
对比维度 |
Amazon SQS |
Amazon SNS |
|
推送与轮询 |
轮询：消费者轮询队列以获取新消息 |
推送：自动将消息推送给订阅者 |
|
接收方类型 |
支持 A2A 通信 |
支持 A2A 与 A2P 通信 |
|
消息保留 |
最长可保留 14 天 |
不存储消息 |
|
消息投递模型 |
支持一对一消息传递 |
支持扇出（一对多）消息传递 |
|
批处理 |
支持消息批处理 |
不支持消息批处理 |
何时使用 SQS
当消息传递系统需要以下能力时，SQS 是云架构中的首选：
- 轮询机制 —— 消费者可自行选择何时轮询消息。
- 异步处理 —— 各服务可独立处理消息。
- 消息保留 —— 最长可保留消息 14 天。
- 消息投递有保障 —— 队列中的消息不丢失。
- 批处理 —— 服务可按批处理消息。
考虑以下真实场景：某电商平台需要处理客户订单，其中包括将订单相关数据写入 RDS 数据库。
使用 Amazon SQS 处理数据的系统架构示意图——图片由作者提供。
在该流程中，客户提交订单后，订单进入 SQS 队列。Lambda 函数（即消费者）轮询队列、接收消息，并将数据写入 RDS 数据库。
在此用例中使用 SQS 有多重优势。由于 SQS 实现了解耦，即便数据库暂不可用，客户仍可提交订单。借助至少一次投递，所有订单都会被处理，避免消息丢失。最后，SQS 支持批处理，可分组处理消息，从而提升效率。
在这里使用 Amazon SNS 则不合适，因为它不保留消息，而会立即将消息推送给 Lambda 函数而不考虑数据库状态。因此，一旦数据库不可用，消息可能丢失。此外，SNS 不支持批处理，只能逐条处理消息，方案不够理想。
何时使用 SNS
当消息传递系统需要以下能力时，SNS 是云架构中的首选：
- 实时通知 —— 以低延迟立即将消息推送给订阅者。
- 扇出分发 —— 多个订阅者可同时接收同一条消息。
- 多种通知订阅者 —— 消息可发送至应用（如 AWS Lambda）与终端用户（如电子邮件）。
设想这样一个场景：开发者监控其 EC2 实例的 CPU 使用率。为确保使用率保持在较低水平，他们希望在 CloudWatch 上监控 CPU 利用率指标，并在超过阈值时接收通知。
Amazon SNS 在此能大显身手，因为它可实时推送通知，同时支持 A2A 与 A2P 流程。借助扇出模式，SNS 可立即向用于缓解问题的 Lambda 函数以及开发者的电子邮箱发送告警通知。
使用 Amazon SNS 进行监控的系统架构示意图——图片由作者提供。
Amazon SQS 在此任务中效果较差，原因在于其消息保留特性。若开发者希望对阈值越界即时响应，就需要实时告警；而消息若被存放在队列中，便无法实现这一点。此外，SQS 基于轮询，只有在消费者轮询时才会访问消息，从而增加延迟。
SQS 与 SNS 搭配使用：优势互补
Amazon SQS 与 Amazon SNS 各具特色，但通过将二者结合，AWS 用户可以构建高效、可扩展且具备容错能力的消息系统，从而充分发挥两者优势。
集成这两项服务并不复杂，因为 SQS 队列可以订阅 SNS 主题。这样，SNS 能够将实时通知发送到 SQS 队列，而 SQS 则负责解耦各流程并确保消息投递。
来看这个例子：某 AWS 开发者正在构建一个文档提交系统，用于从终端用户提交的文档中抽取内容。对于任意提交的文档，该系统需完成两项任务：
- 使用文本处理应用处理文档。
- 向终端用户发送确认电子邮件。
开发者可以将 SQS 与 SNS 结合，打造高效方案：
SNS 与 SQS 协同工作的系统架构示意图——图片由作者提供。
在该流程中，用户提交文档后，消息被发送到 SNS 主题，随后立即推送至 Lambda 函数和 SQS 队列。Lambda 函数负责发送确认邮件，而 SQS 队列则接收并管理消息，供承载文本处理应用的 EC2 实例进行轮询处理。
结语
Amazon SQS 与 SNS 是 AWS 生态中的核心服务，各具优势。SNS 提供实时通知，SQS 提供可靠的消息处理。
针对具体问题的理想消息方案可以采用 SNS、SQS，或二者兼用。只要充分理解两项服务的方方面面，AWS 开发者就能构建满足其独特业务需求的消息解决方案，兼顾效率、可扩展性与韧性。
如果您希望进一步提升 AWS 知识水平，建议学习以下两门进阶课程：
或通过我们的技能路径为 AWS Cloud Practitioner 认证做准备：
FAQs
我可以将 Amazon SQS 和 SNS 与其他 AWS 服务集成吗？
可以。SQS 与 SNS 都能与多种 AWS 服务无缝集成。例如，您可以使用来自 SQS 或 SNS 的消息触发 AWS Lambda 函数，在有新文件上传时向 Amazon S3 发送通知，或使用 Amazon CloudWatch 监控 SQS 与 SNS 的性能。
如何确保使用 SQS 和 SNS 时的消息投递可靠性？
在 SQS 中，您可以使用死信队列（DLQ）捕获多次重试后仍处理失败的消息，确保数据不丢失。对于 SNS，您可以在投递失败时配置重试或回退机制，例如将 SQS 作为 SNS 主题的备份订阅者。
我可以在同一架构中同时使用 SQS 和 SNS 吗？
可以。SQS 与 SNS 可组合构建混合消息架构。例如，SNS 可将实时通知推送至多个消费者，包括 SQS 队列。这样即可同时受益于实时通知（SNS）与可靠、延迟处理（SQS）。
SQS 和 SNS 的计费模式是什么？
SQS 与 SNS 均采用按使用量计费模式。SQS 的费用基于请求次数、数据传输量及长轮询等附加功能。SNS 的费用基于发布消息的数量和投递方式（如电子邮件、短信或 HTTP 端点）。对于高频应用，务必监控使用量以控制成本。
使用 SQS 和 SNS 时如何优化性能？
为优化性能，您可以在 SQS 中使用批处理，一次发送与处理多条消息，从而减少 API 请求与成本。对于 SNS，请确保订阅者能够处理高吞吐量，例如为处理服务（如 Lambda 或 EC2）设置自动伸缩，以高效应对流量峰值。
作为一名有志的数据科学家，我擅长将原始数据转化为可执行的策略。我专注于运用 Python、SQL 和机器学习技术，在数据分析中产出有影响力的解决方案，并构建稳健的 ETL 流水线，用于摄取和处理海量数据。
掌握 AWS 并不轻松，尤其是在理解两项核心服务时：Amazon Simple Queue Service（SQS）与 Amazon Simple Notification Service（SNS）。
尽管二者都是云解决方案中不可或缺的组件，但经常被误解或误用。
本文将解析 SQS 与 SNS 的角色，指出它们的相同与不同，并展示如何将二者结合用于构建高性能的云架构。
SQS 与 SNS：速览
如果您时间紧张，以下是关键差异：
继续阅读以获取更详细的说明，包括用例、架构图与最佳实践！
什么是 Amazon SQS？
Amazon Simple Queue Service（SQS）是一项全托管的消息队列服务，促进软件组件之间的通信。SQS 通过队列解耦微服务，使您能够在应用中构建异步工作流。
SQS 包含三个核心组件：
Amazon SQS 架构示意图，包含主要组件。图片由作者提供。
SQS 提供两种类型的消息队列：
有关这些队列的更多信息，请访问 AWS 文档。
Amazon SQS 以消息持久性为设计核心，可安全存储所有消息直至被处理，确保不丢失。SQS 会先对给定消息进行多次重试；如果在耗尽重试后仍无法处理，您可以将未处理消息存入 死信队列，以便之后审阅与重处理。
通过解耦应用，Amazon SQS 带来诸多益处。它能够承载高消息吞吐量，即便在高并发流量下仍保持高性能。它还支持独立扩展，确保各服务可按自身需求获得足够资源。同时，它通过对消息加密并在多台服务器上存储来提升安全性与持久性。
如需进一步了解该队列系统，欢迎查看我们的 SQS 全面教程。