用SQS模拟SNS中的消息持久化

Question

我们正在评估SNS，以满足我们集成多个应用程序的消息传递需求。我们有一个生产者，它发布消息到SNS的多个主题。每个主题有2-5个订阅者.如果出现订户故障(为了维护)，我有几个问题要问建议的策略，即每个使用者使用SQS队列。

1. 是否可以将SNS配置为只有在向订阅服务器传递消息失败时才将SNS推送到SQS？在SQS队列中转储所有消息会给使用者在重新启动队列时分析队列中的所有消息带来问题。
2. 如果订户失败，它可以在重新启动时从SQS队列中读取消息，但是当它被重载时，它如何知道错过了来自SNS的消息？

欢迎任何有关处理用户故障的建议。

谢谢!

Answer 1

不，这是不可能的“配置SNS推到SQS只有在发生故障”。

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

来自为HTTP/HTTPS端点设置Amazon传递重试策略

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

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

如果它可能离线超过一个小时，您将需要找到一种存储和“重播”消息的方法，可能是通过检查CloudWatch日志。

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

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