使用SQS模拟SNS中的消息持久性

Question

我们正在评估SNS以满足集成多个应用程序的消息传递需求。我们有一个生产者，它将消息发布到SNS上的多个主题。每个主题有2-5个订阅者。如果订阅者失败（为了维护而关闭），我对每个消费者使用SQS队列的推荐策略有几个问题

1. 是否可以将SNS配置为仅在向订阅者传递消息失败的情况下推送到SQS？转储SQS队列中的所有消息会给使用者在重新启动时分析队列中的所有消息带来问题

欢迎就如何处理订户故障提出任何建议。

谢谢！

Answer 1

不，不可能“配置SNS以仅在发生故障时推送到SQS”。

您可以配置Amazon SNS重试策略，而不是在失败后尝试恢复消息。

通过为HTTP/HTTPSendpoint设置Amazon SNS交付重试策略：

您可以使用传递策略不仅控制重试总数，还可以控制每次重试之间的时间延迟。您最多可以指定分布在四个离散阶段中的100次总重试次数。系统中消息的最长生存期为一小时。交付政策不能延长这一小时的限制。

所以，只要目的地在一小时内恢复在线，你就不必担心。

如果可能脱机超过一个小时，您需要找到一种方法来存储和“重播”消息，可能需要检查CloudWatch日志。

或者，还有一个想法...

最初推送到SQS。有一个由SQS触发的AWS Lambda函数。Lambda函数可以执行通常由SNS执行的“推送”。如果失败，标准SQS隐形过程将稍后重试，最终进入死信队列。