为什么亚马逊多次向 SNS 发送确认请求

Question

从 CLI 或 AWS 控制台为 http 端点创建新的 SNS 订阅后，我收到来自 Amazon 的确认订阅请求。我的代码执行确认，然后我收到 Amazon 的响应，表明订阅已通过 SubscriptionArn 成功确认。另外，在 AWS 控制台中，我看到订阅已确认。

但几秒钟后，我又收到了来自亚马逊的确认请求。脚本尝试处理它，但 Amazon 发送了一条错误消息"Subscription already confirmed"。并且这会重复多次。

为什么亚马逊在确认后仍发送确认请求？是否可以检查订阅是否已确认且未执行confirmSubscription？

PS：我使用 NodeJS SDK 来确认订阅。

谢谢

Answer 1

来自SNS 开发者指南：

\n\n

\n

如果 Amazon SNS 没有从您的终端节点收到成功的响应，它会尝试再次传送消息。这适用于所有消息，包括订阅确认消息。

\n

\n\n

从概念上讲，发生的事情似乎一定是这样的：SNS 的一部分（需要确认您的订阅的部分）本质上询问了 SNS 的另一部分（将 HTTP 消息传递到 HTTP 端点的部分）将消息传送到您的端点。在本例中，它是确认消息。

\n\n

与任何其他消息一样，原始发件人不会被询问是否应重试失败的消息 - SNS 只是重试。即使原始发送者恰好是 SNS 的不同内部部分（如订阅确认的情况），这似乎仍然成立，这似乎是明智的。

\n\n

不使用告诉 SNS 您收到消息的 HTTP 响应代码进行响应，会导致 SNS 在几秒钟后重试...因此，即使同时您已经确认了您的订阅，SNS 中负责传递消息的部分你不知道这一点——它只知道，从它的角度来看，有一条你显然没有收到的消息，这意味着重试。

\n\n

x-amz-sns-message-id:每次重试时，正在重试的消息都将具有相同的请求标头。这使您能够区分重试的消息和看似与先前消息相同但实际上是具有相同负载的不同消息的消息。

\n\n

在上面链接的同一页面上，在分配的时间内任何介于 200 和 499 之间的响应代码都被视为成功交付。

\n\n

\n

确保您的终端节点POST使用适当的状态代码响应来自 Amazon SNS 的 HTTP 消息。连接将在 15 秒后超时。如果您的终端节点在连接超时之前未响应，或者您的终端节点返回超出 200\xe2\x80\x934xx 范围的状态代码，Amazon SNS 会将消息传送视为失败的尝试。

\n

\n\n

在“成功”概念中包含 4xx 状态代码似乎违反直觉，直到您考虑“传递”含义的概念 - 这意味着您的端点确实收到了消息。4xx 响应表明您的端点在某种程度上不喜欢该消息，但该消息确实已传递。这与 5xx 错误形成对比，从一般意义上讲，5xx 错误意味着您的端点（至少目前为止）无法处理消息。

\n\n

此行为还表明了另一种设计考虑：作为针对“丢失”确认尝试的故障保护，如果您的应用程序尝试联系 SNS 端点以完成确认失败，您的应用程序应返回 5xx 错误以返回到 SNS，以便 SNS将重试，该过程随后可能会成功。

\n