SQS 返回的消息多于队列大小答案

【问题标题】：SQS returns more messages than queue sizeSQS 返回的消息多于队列大小
【发布时间】：2016-12-25 19:51:37
【问题描述】：

我创建了一个基本的非 FIFO 队列，并且只在其上放置了 1 条消息。我使用以下代码检索消息：

ReceiveMessageRequest request = new ReceiveMessageRequest();
request.setQueueUrl(queueUrl);
request.setMaxNumberOfMessages(10);
request.withMessageAttributeNames("All");
ReceiveMessageResult result = sqsClient.receiveMessage(request);
List<Message> messages = result.getMessages();

messages.size() 给出 3

他们有：

相同的 MessageId
相同的正文和属性
相同的 MD5OfBody
不同的收据句柄

将MaxNumberOfMessages 从 10 更改为 1 修复了它，但我希望将来分批接收 10 个。

有人可以解释为什么它检索的消息比它应该的多吗？

下面是我的队列配置：

Default visibility timeout = 0
message retention = 4 days
max message size = 256kb
delivery delay = 0
receive message wait time = 0
no redrive policy

【问题讨论】：

标签： amazon-web-services amazon-sqs

【解决方案1】：

@Michael 的详细信息/补充 - sqlbot 评论。

将SQS visibility timeout 设置为较小的值并不能解决您的问题。您将再次遇到问题。使用 30 秒或更长时间以允许您的程序使用该消息。（为了应对程序崩溃/意外的程序延迟，您应该创建重新驱动策略来缓解这些问题。）

AWS 在At-Least-Once Delivery 中提到了这一点

Amazon SQS 将您的消息副本存储在多个服务器上冗余和高可用性。在极少数情况下，其中之一存储邮件副本的服务器可能不可用接收或删除消息。

如果发生这种情况，邮件副本将不会被删除服务器不可用，并且您可能会再次获得该消息副本接收消息。您应该将应用程序设计为幂等的（它们在处理相同的内容时不应受到不利影响消息不止一次）。

【讨论】：

【解决方案2】：

将 Default Visibility Timeout 从 0 秒更改为 1 秒解决了这个问题

【讨论】：

1 和 0 都不可能是默认可见性超时的合适值。这几乎可以肯定是太短了。可见性超时是 SQS 在假定您已崩溃或遇到错误之前等待您删除消息的时间量，它会再次重新传递消息，可能是给您，也可能是给同一队列的另一个消费者，假设您已经失败并且以某种方式丢失了消息，并且需要再次接收（和处理）它。