使用SQS在SNS中模拟消息持久性 [英] Simulating message persistence in SNS using SQS

问题描述

我们正在评估SNS的消息传递要求，以集成多个应用程序.我们只有一个生产者，可以将消息发布到SNS上的多个主题.每个主题有2-5个订阅者.如果订户发生故障(为了维护而停机)，我对使用每个消费者使用SQS队列的推荐策略有一些疑问

We are evaluating SNS for our messaging requirements to integrate multiple applications. we have a single producer that publishes messages to multiple topics on SNS. Each topic has 2-5 subscribers. In event of subscriber failures (down for maintenance) I have a few questions on the recommended strategy of using SQS queues per consumer

1. 是否可以将SNS配置为仅在将消息传递给订户失败的情况下才推送到SQS?将SQS队列中的所有消息都转储会给消费者带来一个问题，供使用者在重新启动队列时分析队列中的所有消息.
2. 如果订户发生故障，它可以在重新启动时从SQS队列中读取消息，但是当过载时，它怎么知道它错过了SNS的消息呢?

欢迎提供任何处理订户故障的建议.

Any suggestions on handling subscriber failures are welcome.

谢谢！

推荐答案

否，不可能将SNS配置为仅在发生故障时才推送到SQS".

No, it is not possible to "configure SNS to push to SQS only in event of failure".

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

Rather than trying to recover a message after a failure, you can configure the Amazon SNS retry policies.

从设置HTTP/HTTPS终端节点的Amazon SNS交付重试策略:

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

You can use delivery policies to control not only the total number of retries, but also the time delay between each retry. You can specify up to 100 total retries distributed among four discrete phases. The maximum lifetime of a message in the system is one hour. This one hour limit cannot be extended by a delivery policy.

因此，只要目的地在一小时内恢复在线，您就不必担心.

So, you don't need to worry as long as the destination is back online within an hour.

如果它可能离线超过一个小时，则可能需要通过检查

If it is likely to be offline for more than an hour, you will need to find a way to store and "replay" the messages, possibly by inspecting CloudWatch Logs.

或者，这是另一个想法...

Or, here's another idea...

最初将其推送到SQS.具有由SQS触发的AWS Lambda函数.Lambda函数可以执行通常由SNS完成的推送".如果失败，则标准的SQS隐形过程将稍后重试，最终进入死信队列".

Push initially to SQS. Have an AWS Lambda function triggered by SQS. The Lambda function can do the 'push' that would normally be done by SNS. If it fails, then the standard SQS invisibility process will retry it later, eventually going to a Dead Letter Queue.

这篇关于使用SQS在SNS中模拟消息持久性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！