Amazon SNS vs. Amazon SQS – 亚马逊 SNS 与亚马逊 SQS

1. Introduction

1.导言

In this tutorial, we’ll talk about two of the top services that AWS provides to users: SNS and SQS. First of all, we’ll have a short description of one and the other, peeking at some simple use cases. Then we’ll point out the main differences between them, looking from different angles. Finally, we’ll see how those services express great power and capabilities when coupled together.

在本教程中，我们将讨论 AWS 为用户提供的两项顶级服务：SNS 和 SQS。首先，我们将简要介绍这两种服务，并介绍一些简单的使用案例。然后，我们将从不同角度指出它们之间的主要区别。最后，我们将看到这些服务结合在一起时如何展现出强大的功能和能力。

2. SNS Definition and Use Cases

2.SNS 定义和用例

Users utilize Amazon Simple Notification Service as a managed service for sending real-time notifications. To understand SNS easily, we can focus specifically on three objects: the topic, the publisher, and the subscriber. One topic can receive messages from multiple publishers and can deliver the same message to multiple subscribers. Every message a publisher sends to the topic will reach all subscribers registered:

用户利用亚马逊简单通知服务作为发送实时通知的托管服务。为了便于理解 SNS，我们可以特别关注三个对象：主题、发布者和订阅者。一个主题可以接收来自多个发布者的消息，也可以向多个订阅者发送相同的消息。发布者向主题发送的每条消息都将到达所有注册的订阅者：

Let’s talk about the journey of a message from a publisher to a subscriber. First of all, both publishers and subscribers need to have permission to read and write from the SNS topic. We can define permissions with IAM Access Policies. Then, when the message reaches the topic, it’s stored in an encrypted-at-rest storage that is used to retry the delivery of the message if something fails.

让我们来谈谈消息从发布者到订阅者的过程。首先，发布者和订阅者都需要有从 SNS 主题读写的权限。我们可以使用 IAM 访问策略来定义权限。然后，当消息到达主题时，它会被存储在一个加密的静态存储器中，用于在出现故障时重试消息的发送。

Looking at the image, we can observe that there are two types of topics: Standard and FIFO. The key differentiation lies in the fact that only the latter ensures that the sequence of message delivery matches the order of their publication.

观察图片，我们可以发现有两类主题：标准主题和先进先出主题。区别的关键在于，只有后者才能确保信息发送的顺序与信息发布的顺序一致。

Prior to dispatching messages, they undergo a procedure that involves the activation of Data Protection Policies. These policies are crafted to furnish an elevated level of safeguarding for Personally Identifiable Information (PII) and other forms of sensitive data. Techniques such as data masking are implemented as integral components of this protective process.

在发送信息之前，它们要经过一个程序，其中包括激活数据保护政策。这些政策旨在为个人身份信息 (PII) 和其他形式的敏感数据提供更高级别的保护。数据屏蔽等技术是这一保护程序不可或缺的组成部分。

Finally, subscribers can receive the message using various protocols. It’s also possible to define specific filtering policies for every subscriber so that some messages are discarded and not sent, and a Dead Letter Queue (SQS queue) to handle delivery failures and manual retries for a specific subscriber.

最后，订阅者可以使用各种协议接收邮件。还可以为每个订阅者定义特定的过滤策略，从而丢弃和不发送某些邮件，并定义死信队列（SQS 队列）来处理特定订阅者的发送失败和手动重试。

Users can deliver time-critical notifications using Amazon SNS. For example, with a monitoring tool such as Datadog, we can use SNS to send system alerts triggered by predefined thresholds in case something in our application is misbehaving. Another example could be to use SNS as a messaging system to send updates to every user subscribed to our application, using email, SMS, and mobile push notifications. SNS with SQS is the fundamental building block of any AWS Cloud Based application for implementing the “Fanout” scenario.

用户可以使用 Amazon SNS 发送时间关键型通知。例如，通过 监控工具（如 Datadog），我们可以使用 SNS 发送由预定义阈值触发的系统警报，以防我们的应用程序出现异常。另一个例子是将 SNS 用作消息系统，使用电子邮件、SMS 和移动推送通知向订阅我们应用程序的每个用户发送更新。带有 SQS 的 SNS 是任何基于 AWS 云的应用程序实现 “Fanout “场景的基本构件。

3. SQS Definition and Use Cases

3.SQS 定义和用例

Amazon launched AWS SQS Simple Queue Service back in 2004 and it was one of the first managed services available to users. It has become one of the fundamental building blocks of many cloud-based applications. It finds its primary use in enabling asynchronous communication between different software components. We know from experience that managing a queue presents a series of challenges, such as the bounded-buffer problems, and that managing a distributed queue is even more difficult because of the communication that we need to enable between components to manage concurrent writes and reads. SQS helps solve all those problems in an easy way.

亚马逊早在 2004 年就推出了 AWS SQS 简单队列服务，这也是最早向用户提供的托管服务之一。它已成为许多基于云的应用程序的基本构建模块之一。它的主要用途是实现不同软件组件之间的异步通信。我们从经验中了解到，管理队列会带来一系列挑战，例如有界缓冲区问题，而管理分布式队列则更加困难，因为我们需要在组件之间实现通信，以管理并发写入和读取。SQS 可以帮助我们轻松解决所有这些问题。

Let’s now talk about a message’s journey from a publisher to a subscriber. The first part is similar to SNS: publishers and subscribers need permission to read and write from the SQS queue. As in SQS, we can define those permissions with IAM Access Policies. Then, when the message reaches the queue, the system stores it in encrypted-at-rest storage. A delivery retry mechanism will read from this storage if something fails.

现在我们来谈谈消息从发布者到订阅者的过程。第一部分与 SNS 类似：发布者和订阅者需要有从 SQS 队列读写的权限。在 SQS 中，我们可以使用 IAM 访问策略来定义这些权限。然后，当消息到达队列时，系统会将其存储在加密的静态存储中。如果出现故障，交付重试机制将从该存储中读取。

The queue, in this case, can be Standard, FIFO, or Delay. We can pick a FIFO queue to maintain the ordering or a delay queue to delay the delivery of the message by a predefined amount of time. The consumer can read from the queue using two different mechanisms: short polling and long polling.

在这种情况下，队列可以是标准队列、先进先出队列或延迟队列。 消费者可以使用两种不同的机制从队列中读取信息：短轮询和长轮询。

Any use case in which we need a decoupling of communication between software components could make good use of the SQS service. For example, in the SNS infrastructure, SQS serves as the underlying implementation of the Dead Letter Queue, handling delivery failures and manual retries for a specific subscriber.

任何需要软件组件间通信解耦的用例都可以很好地利用 SQS 服务。例如，在 SNS 基础架构中，SQS 是死信队列的底层实现，用于处理特定订阅者的发送失败和手动重试。

4. SNS vs. SQS: Differences

4.SNS 与 SQS：区别

Let’s now summarize the key differences between SQS and SNS:

现在让我们总结一下 SQS 和 SNS 之间的主要区别：

5. Why Coupling SNS and SQS Together?

5.为什么要将 SNS 和 SQS 结合在一起？

The “fanout” scenario is the typical use case in which we need both SNS and SQS working together. In this case, messages are sent from SNS topics and then replicated to different SQS queues. The queues are subscribed to the service. This, of course, allows for parallel asynchronous processing.

扇出 “场景是我们需要 SNS 和 SQS 协同工作的典型用例。在这种情况下， 消息从 SNS 主题发送，然后复制到不同的 SQS 队列。这些队列都订阅了服务。当然，这允许并行异步处理。

For example, let’s suppose we need to build a video streaming platform. When a user uploads a new video, we publish an SNS message to a topic with the link to the item (stored in an S3 bucket). The topic establishes connections with several SQS queues. The queues will process (concurrently) different encoding and video quality for the same video. Then, a series of independent applications read from those queues and process the workload asynchronously:

例如，假设我们需要建立一个视频流平台。当用户上传新视频时，我们会向一个主题发布一条 SNS 消息，并附上项目链接（存储在 S3 bucket 中）。该主题会与多个 SQS 队列建立连接。队列将（并发）处理同一视频的不同编码和视频质量。然后，一系列独立的应用程序从这些队列中读取并异步处理工作负载：

The Dead-Letter Queue used to retry SNS message delivery is another example of using SNS and SQS together. In this way, clients and applications achieve real-time communication with better resiliency and fault tolerance.

用于重试 SNS 消息传递的死信队列（Dead-Letter Queue）是同时使用 SNS 和 SQS 的另一个例子。通过这种方式，客户端和应用程序可以实现实时通信，并具有更好的弹性和容错性。

6. Conclusion

6.结论

In this article, we have described two of the most used software solutions of the AWS Cloud Provider: the Simple Queue Service and the Simple Notification Service. We discussed the key characteristics, we peeked at the basic functionalities, and we compared the most important features. Finally, we shared a common example of usage in which SNS and SQS combined solve some typical software design problems.

在本文中，我们介绍了 AWS 云提供商最常用的两个软件解决方案：简单队列服务（Simple Queue Service）和简单通知服务（Simple Notification Service）。我们讨论了它们的主要特点，了解了它们的基本功能，并对最重要的功能进行了比较。最后，我们分享了一个常见的使用示例，在这个示例中，SNS 和 SQS 共同解决了一些典型的软件设计问题。