了解 AWS SQS 可见性超时

Question

在我的 AWS 基础设施中，我有一个 SQS 队列和一个 Lambda 函数。 SQS 队列的可见性超时设置为 0，没有传送延迟，receiveMessageWaitTime 为 0。SQS 队列的 DLQ 的最大接收计数为 2。Lambda 函数使用 AWS 开发工具包的 SQS 从 SQS 队列进行消费客户。这个 lambda 只有一个实例在运行，因此它的并发度永远不会大于 1。我最基本的思路是，如果 SQS 队列中有 4 条消息，则将按顺序发生以下步骤：

1. Lambda 函数创建 receiveMessage 请求并轮询 SQS 队列中的任何消息。
2. Lambda 函数接收来自 SQS 的响应，其中包含许多消息。
3. Lambda 函数处理这些消息。
4. Lambda 函数根据收据句柄删除每条消息。
5. 重复步骤1：再次轮询SQS队列。重要提示：我假设已处理的消息已被删除并且将不再可见。

在实践中，这似乎有所不同：

1. Lambda 函数创建 receiveMessage 请求并轮询 SQS 队列中的任何消息。
2. Lambda 函数接收来自 SQS 的响应，其中包含许多消息。
3. Lambda 函数处理这些消息。
4. Lambda 函数根据收据句柄删除每条消息。
5. 重复步骤1：再次轮询SQS队列。但是，具有相同消息 id 但不同接收句柄的消息将被消费。此外，消息最终会出现在 DLQ 中。

这似乎是由可见性超时引起的，我将其设置为 0（当我增加此参数的值时，处理按预期进行）。但是，我无法理解以下内容：

当我轮询消息时，我从 SQS 收到一组特定的消息。然后，投票停止。在再次轮询之前，我删除了已处理的消息。在单次轮询期间（我执行长轮询，10 秒），我收到相同的消息，但收到的消息不同，但消息 ID 相同，两次甚至多次。这是什么原因呢？我可以想象，当我（仍在）轮询时，我已经从 SQS 收到的消息立即再次可用，并在 receiveRequest 返回响应之前第二次收到。我想更深入地了解这个过程是如何工作的，特别是关于 SQS 的分布式性质。

Answer 1

简单答案：您应该将不可见超时设置为处理消息所需的预期时间的几倍。

详细答案： 当从 Amazon SQS 队列检索消息时，它会变得不可见。这意味着该消息在此期间不会提供给任何其他消费者。如果消费者失败，那么消息最终将重新出现在队列中以进行重新处理（假设某些事情失败）。另一方面，如果消费者成功删除该消息，那么该消息将从队列中删除。

来自 Amazon SQS 可见性超时 - Amazon Simple Queue Service：

通常，您应该将可见性超时设置为应用程序处理消息并从队列中删除消息所需的最长时间。

将不可见超时设置为零是没有意义的，因为它会导致您遇到的问题。