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

Question

在从CLI或AWS控制台为httpendpoint创建新的SNS订阅后，我从Amazon收到确认订阅的请求。我的代码执行确认，然后我从Amazon得到响应，即订阅已用subscriptionarn成功确认。同样在AWS控制台中，我看到订阅被确认。

但几秒钟后，我收到了另一个来自亚马逊的确认请求。脚本试图处理它，但Amazon发送了一个错误消息“subscription已经确认”。而这又重复了好几次。

为什么亚马逊在确认后还会发送确认请求？是否可以检查订阅是否已确认，而不执行confirmsubscription？

谢谢

Answer 1

摘自SNS开发人员指南：

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

从概念上讲，发生的事情似乎是这样的：SNS的一部分（需要确认您的订阅的部分）本质上要求SNS的另一部分（向HTTPendpoint传递HTTP消息的部分）向您的endpoint传递消息。在本例中，是确认消息。

如果不使用HTTP响应代码告诉SNS您收到了消息，则SNS会在几秒钟后重试...因此，即使同时你已经确认了你的订阅，负责向你发送消息的SNS也不知道--从它的角度来看，它只知道你显然没有收到一条消息，这意味着要重试一次。

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

在上面链接的同一页面中，在分配的时间内，任何在200到499之间的响应代码都被认为是成功的传递。

确保您的endpoint使用适当的状态html" target="_blank">代码响应来自Amazon SNS的HTTPpost消息。连接将在15秒后超时。如果您的endpoint在连接超时之前没有响应，或者如果您的endpoint返回200-4xx范围之外的状态代码，Amazon SNS将认为消息的传递是一次失败的尝试。

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

这个行为还建议了另一个设计考虑：作为防止“丢失”确认尝试的故障安全，如果您的应用程序尝试联系SNSendpoint以完成确认失败，您的应用程序应该返回一个5xx错误到back to SNS，这样SNS将再次尝试，该过程可能随后成功。