Amazon SQS 可见性超时 - Amazon Simple Queue Service
设置可见性超时飞行中的消息和配额了解标准FIFO队列和队列中的可见性超时如果消费者未能处理消息会发生什么更改和终止可见性超时最佳实践

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon SQS 可见性超时

当消费者收到来自 Amazon SQS 队列的消息时，该消息会保留在队列中，但其他消费者暂时看不见。这种暂时的隐身性由可见性超时控制，这是一种防止其他使用者在处理同一消息时处理该消息的机制。Amazon SQS 不会自动删除该消息；相反，消费者必须在消息成功处理后使用DeleteMessage操作将其明确删除。

显示可见性超时期间请求处理方式的时间线图

设置可见性超时

当一条消息返回给消费者时，Amazon 中的可见性超时就SQS开始了。在这段时间内，消费者需要处理和删除消息。但是，如果消费者未能在可见性超时到期之前删除消息，则该消息将在队列中再次可见，并且可以由其他使用者检索。

每个 Amazon SQS 队列的默认可见性超时为 30 秒，但您可以根据应用程序的需求调整此设置。通常，最好将可见性超时设置为与应用程序处理和删除消息所需的最长时间相匹配。您也可以为单个消息配置特定的可见性超时，而无需更改队列的总体超时设置。

飞行中的消息和配额

在 Amazon SQS 中，传输中的消息是指消费者从队列中收到但尚未删除的消息。对于标准队列，传输中的消息数量有限制，最多可以约为 120,000，具体取决于队列流量和消息积压。

  • 短轮询 — 如果在使用短轮询时达到此限制，Amazon SQS 将返回OverLimit错误，表示在删除某些正在处理的消息之前，无法收到其他消息。

  • 长轮询 — 如果您使用的是长轮询，则当达到传输中的邮件限制时，Amazon SQS 不会返回错误。相反，在传输中的消息数量降至限制以下之前，它不会返回任何新消息。

要有效管理机上消息并避免达到此配额，请执行以下操作：

  1. 提示删除-确保成功处理邮件后立即将其删除，以减少正在处理的数量。

  2. 监控方式 CloudWatch — 使用 Amazon CloudWatch 监控传输中消息的数量，并设置警报以在接近限制时提醒您。

  3. 分配负载-如果您要处理大量消息，请考虑增加队列数量，以分散负载并防止出现瓶颈。

  4. 申请增加配额 — 如有必要，请将支持请求提交至 AWS 以增加应用程序的动态消息配额。

了解标准FIFO队列和队列中的可见性超时

Amazon 中的可见性超时SQS管理标准和FIFO队列中的消息处理，以防止重复处理并保持消息顺序。

  • 标准队列-在标准队列中，可见性超时有助于防止多个使用者同时处理同一条消息。但是，由于 Amazon 的至少一次传送模式SQS，因此无法绝对保证在可见性超时期间消息不会超过一次传送。

  • FIFOq ueues — 在FIFO（先进先出）队列中，可见性超时可确保按正确的顺序处理具有相同消息组 ID 的消息。如果消费者在可见性超时到期之前没有删除消息，则在消息再次可见或被删除之前，不会发送具有相同群组 ID 的新消息。对于FIFO队列，谨慎管理可见性超时以保持消息顺序和处理完整性尤为重要。

如果消费者未能处理消息会发生什么

如果消费者由于应用程序错误、崩溃或连接问题等问题而未能处理消息，并且在可见性超时到期之前没有删除该消息，则该消息会自动在队列中再次可见。消息一经可见，即可由同一个或不同的使用者检索，以进行另一次处理尝试。此过程可确保即使初始处理失败，也不会丢失消息。

但是，需要注意的是，如果将可见性超时设置得太高，则会延迟未处理消息的重新出现，从而可能会减慢重试的速度。根据预期的处理时间设置适当的可见性超时对于及时处理消息至关重要。

更改和终止可见性超时

根据您的需求，SQS使用ChangeMessageVisibility操作来管理消息处理，更改或终止 Amazon 中的可见性超时。

  • 更改超时-如果初始可见性超时不足，则可以使用ChangeMessageVisibility操作进行调整。此操作允许您根据处理需求缩短或延长超时时间。

  • 终止超时-如果您决定不处理收到的消息，则可以通过将ChangeMessageVisibility操作设置为 0 秒来终止其可见性超时。VisibilityTimeout这会立即使消息可供其他使用者处理。

最佳实践

使用以下最佳实践来管理 Amazon 中的可见性超时SQS，包括设置、调整和延长超时时间，以及使用 Dead-Letter Queues () 处理未处理的消息。DLQs

  • 设置和调整超时时间。首先，将可见性超时设置为与您的应用程序通常需要处理和删除消息的最长时间相匹配。如果您不确定确切的处理时间，请从较短的超时时间（例如 2 分钟）开始，然后根据需要延长。您可以实现心跳机制来定期延长可见性超时时间，从而确保消息在处理完成之前保持不可见状态。这样可以最大限度地减少重新处理未处理的邮件的延迟，并防止过早可见。

  • 延长超时时间并处理 12 小时限制。如果您的处理时间不同或可能超过最初设置的超时时间，请在处理消息时使用ChangeMessageVisibility操作延长可见性超时。请记住，自首次收到消息之日起，可见性超时的最大限制为 12 小时。延长超时时间不会重置此 12 小时限制。如果您的处理时间超过此限制，请考虑使用 AWS Step Functions 或者将任务分成较小的步骤。

    实际上，如果在接收消息和更新超时之间存在延迟，则立即将可见性超时设置为完整的 12 小时限制可能会失败。为避免这种情况，请使用稍低一点的值，例如 43,195 秒。

  • 处理未处理的消息要管理多次处理尝试失败的消息，请配置 Dead-Letter Queue ()。DLQ这样可以确保单独捕获多次重试后无法处理的消息以供进一步分析或处理，从而防止它们在主队列中重复传播。