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

【问题标题】：Why Amazon sends confirmation request for SNS several times为什么亚马逊多次发送 SNS 确认请求
【发布时间】：2017-03-12 04:25:24
【问题描述】：

从 CLI 或 AWS 控制台为 http 端点创建新的 SNS 订阅后，我收到来自亚马逊的确认订阅的请求。我的代码执行确认，然后我收到来自 Amazon 的响应，即使用 SubscriptionArn 成功确认订阅。同样在 AWS 控制台中，我看到订阅已确认。

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

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

P.S.：我使用 NodeJS SDK 来确认订阅。

谢谢

【问题讨论】：

您是否在收到传入消息时没有返回正确的响应（如200 OK）？这是有道理的——SNS 的一部分被要求“传递一些东西”......这恰好是向您发送消息的确认。它正在重试，因为它认为它未能交付“某些东西”。听起来该服务并不是故意要求您再次确认，而是它只是在做它应该对它应该提供的 anything 做的事情——就像它使用普通的 SNS 通知一样——重试-- 当你没有以肯定的方式回应时。
@Michael-sqlbot 是的，你是对的，我忘记在确认后发送回复。您可以写下您的评论作为答案，我会接受。

【解决方案1】：

来自SNS Developer Guide：

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

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

与任何其他消息一样，原始发件人不会被询问是否应重试失败的消息 - SNS 只是重试它。即使原始发件人碰巧是 SNS 的不同内部部分，这似乎仍然适用，就像订阅确认的情况一样。

未使用告诉 SNS 您收到消息的 HTTP 响应代码进行响应会导致 SNS 在几秒钟后重试...因此，即使同时您已经确认订阅，SNS 的已分配任务的部分向您发送消息时并没有意识到这一点 - 从它的角度来看，它只知道有一条您显然没有收到的消息，这意味着重试。

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

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

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

在“成功”的概念中包含 4xx 状态代码似乎违反直觉，除非您考虑到“交付”的含义——这意味着您的端点确实接收了消息。 4xx 响应表明您的端点在某种程度上没有喜欢该消息，但该消息确实已送达。这与 5xx 错误形成鲜明对比，5xx 错误在一般意义上意味着您的端点（至少在目前）无法处理该消息。

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

【讨论】：