Amazon web services AWS SQS-复制的消息何时到达？

我知道标准SQS使用“至少一次”传递，而FIFO消息只传递一次。我试图为我的应用程序权衡标准队列与FIFO，其中一个因素是复制消息到达所需的时间

我打算使用来自SQS的消息，然后将收到的数据发布到幂等第三方API。我知道，使用标准SQS时，总是存在使用旧的重复数据覆盖较新数据的风险

例如：

Message A arrives, I post it onwards.
Message A duplicate arrives, I post it onwards.
Message B arrives, I post it onwards.
All fine ✓

另一方面：

Message A arrives, I post it onwards.
Message B arrives, I post it onwards.
Message A duplicate arrives - I post it and overwrite the latest data, which was B! ✖

---

我想衡量这种风险，也就是说，我想知道重复邮件到达需要多长时间。重复的消息到达的时间是否与原始消息大致相同？

了解消息重复是如何发生的可能很有用。据我所知，这并没有在官方文件中记录，而是我的思维模式这是一个有根据的猜测。

每当您向SQS（

SendMessage

API）发送消息时，此消息都会到达SQS webservice端点，该端点可能是数千台服务器之一。此端点接收您的消息，将其复制一次或多次，并将这些重复项存储在多个SQS服务器上。在收到来自至少两个SQS服务器的确认后，它向客户端确认消息已被接收

调用

ReceiveMessage

API时，仅查询处理队列的SQS服务器的一个子集以获取消息。当返回消息时，这些服务器将与其对等服务器通信，该消息当前正在传输中，并且可见性超时开始。这不是瞬间发生的，因为它是一个分布式系统。当此

ReceiveMessage

调用发生时，另一个消费者也可能执行

ReceiveMessage

调用，并在消息标记为正在运行之前，碰巧查询具有消息副本的其中一个服务器。该服务器分发消息，现在您必须向正在处理该消息的消费者发送消息

这只是一个场景，这是分布式系统的结果。 由于网络问题，可能会出现一些边缘情况，例如，当SQS对初始

SendMessage

的响应丢失时，客户端认为消息没有到达并再次发送-poof，您又收到了一个副本

重点在于：事情以奇怪而复杂的方式失败。这使得衡量延迟消息的风险变得困难。如果您的用例不能处理重复的和无序的消息，您应该使用FIFO，但这将固有地限制您的吞吐量。替代方案基于分布式锁定机制，并跟踪您已经处理的消息，这是解决复杂问题的复杂工具