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