据我所知，为了带来巨大的可扩展性和可靠性，SQS可以进行广泛的资源并行化。它使用冗余服务器甚至是小队列，甚至发布到队列的消息也作为多个副本冗余存储。这些是阻止它像RabbitMQ那样完全一次交付的因素。我甚至看到过已删除的邮件。
对开发人员的影响是他们需要为多个消息传递做好准备。亚马逊声称这不是一个问题，但事实上，开发人员必须使用一些同步构造，如数据库事务锁或dynamo-db条件写。这两者都降低了可扩展性。
鉴于重复发送问题，消息不可见时段功能如何保存？该邮件不保证不可见。如果开发者必须自己安排同步，那么隐形期间会带来什么好处。我已经看到消息重新发送，即使它们应该是隐形的。
这里我包含一些参考文献
答案 0 :(得分：16)
消息隐身解决了另一个问题，即只保证一次交付。考虑队列中项目的长时间运行操作。如果处理器在操作期间出现故障，您不希望删除该消息，您希望它再次出现并由另一个处理器再次处理。
所以模式是......
因此，无论您是否获得重复交付，您仍需要确保处理队列中的项目。如果在将其从队列中拉出来删除它，然后您的服务器终止，您可能会永远丢失该消息。它可以通过使用现场实例进行积极扩展 - 并保证（使用上述模式），您不会丢失消息。
但是 - 它不保证一次也只保证一次交付。但我不认为它是针对这个问题而设计的。我也不认为这是一个不可逾越的问题。在我们的案例中（我可以看到为什么我以前从未注意到这些问题） - 我们正在将结果写入S3。如果它用相同的数据覆盖相同的文件，那没什么大不了的。当然，如果这是一个转账到银行A / C的借记交易，你可能想要某种相关ID ......大多数系统已经有了那些。因此，如果您获得重复的相关值，则抛出异常并继续前进。
好问题。突出显示了一些东西给我。