我是使用 AWS 服务的初学者。我最近有一个要求，我想将一些数据从服务 1 发送到服务 2 和服务 3。所以，我想做的是，我将从服务 1 和服务 2 和服务 3 向 SNS 推送通知此 SNS 主题的订阅者。因此，这就是多个订阅者订阅同一个主题并且两个订阅者都想要相同数据的情况。
我对 AWS SNS 的基本功能有一些疑问。如果有人可以在这方面提供帮助，那将非常有帮助。
假设有 2 个通知 A、B 推送到 SNS 主题，那么两个订阅者都会收到两个通知吗？
同样的场景，2条通知什么时候从SNS主题中删除？
SNS 是否将通知存储在某处？或者它只是将消息传递给订阅者？
如果其中一个订阅者失败并且无法获得某些通知，会发生什么情况？当它再次连接到 SNS 主题时会收到这些通知还是不会收到这些通知？
请提供您对上述部分问题的回答。这些确实有助于我了解 SNS 在内部是如何工作的。
感谢您的帮助。
【问题讨论】：
标签： amazon-web-services notifications amazon-sns
发送到 SNS 主题的消息会发送给所有订阅者。
发布者向主题发送消息。发布新消息后，Amazon SNS 会尝试将该消息传递到订阅该主题的每个终端节点。 （强调）
消息实际上并没有从主题中“删除”（您可能会想到 SQS）......但它们也不会持续存在。它们发布了，然后就消失了。
一个明显的例外——retry policies——并不是真正的例外。在这种情况下，消息已经发布，并且从概念上讲已经从主题中消失，但 SNS 仍然可以重试传递到特定目标。
SNS 所做的一切都是推送。订阅者不连接到 SNS 并请求消息。消息发布后，即被发布。未来的订阅者将永远不会看到旧消息，“错过”它的订阅者也不会回来获取它。
但是...SNS fanout 可以将消息发送到多个 SQS 队列。在这种情况下，您将队列订阅到主题，并使用队列中的消息。每个队列获取每条消息的副本，并且每个队列中的一个消费者在轮询 SQS 时都会收到一份副本。
SQS 队列也是一个很好的备份临时消息保留位置。如果您将 SNS 消息发送到其他类型的端点——例如 HTTPS 或 Lambda，您也可以将消息发送到 SQS 队列，但在正常操作下，实际上不要轮询队列。邮件将在maximum message retention period 之后自动从队列中清除，默认为 4 天，但最多可配置为 14 天。如果主题订阅者出现任何问题并且消息丢失，您可以从这个备份队列中检索它们，否则它们最终会在超时到期时自行消失。队列中可以等待、未读的消息数量没有限制。
【讨论】：