Amazon SQS 可见性超时 - Amazon Simple Queue Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

Amazon SQS 可见性超时

当您收到来自 Amazon SQS 队列的消息时,它会保留在队列中,但其他用户暂时看不见。这种隐身性由可见性超时控制,这可确保其他使用者在处理同一条消息时无法处理该消息。Amazon SQS 提供了两种在处理后删除消息的选项:

  • 手动删除-使用DeleteMessage操作可以显式删除消息。

  • 自动删除-某些情况下支持 Amazon SDKs,成功处理邮件后会自动删除,从而简化工作流程。

时间线图:在可见性超时期间,系统如何处理消息

可见性超时用例

管理长时间运行的任务-使用可见性超时来处理需要延长处理时间的任务。为需要延长处理时间的消息设置适当的可见性超时。这样可以确保其他消费者在处理同一消息时不会收到相同的消息,从而防止重复工作并保持系统效率。

实现重试机制-以编程方式延长在初始超时内未能完成的任务的可见性超时。如果任务未能在初始可见性超时内完成,则可以通过编程方式延长超时时间。这允许您的系统在其他用户看不到消息的情况下重试处理消息,从而提高容错能力和可靠性。与 Dead-Letter Queues (DLQs) 结合使用以管理持续故障。

协调分布式系统-使用SQS可见性超时来协调分布式系统中的任务。设置可见性超时,使其与不同组件的预期处理时间保持一致。这有助于在复杂的分布式架构中保持一致性并防止竞争条件。

优化资源利用率-调整SQS可见性超时以优化应用程序中的资源利用率。通过设置适当的超时,可以确保消息得到高效处理,而不会不必要地占用资源。这可以提高整体系统性能和成本效益。

设置和调整可见性超时

消息传送给您后,可见性超时即开始。在此期间,您需要处理和删除该消息。如果您没有在超时到期之前将其删除,则该消息将在队列中再次可见,并且可以由其他使用者检索。队列的默认可见性超时为 30 秒,但您可以将其调整为与应用程序处理和删除消息所需的时间相匹配。您也可以在不更改队列整体设置的情况下为单条消息设置特定的可见性超时。根据需要,使用ChangeMessageVisibility操作以编程方式延长或缩短超时时间。

飞行中消息和配额

在 Amazon 中SQS,传输中的消息是消费者已收到但尚未删除的消息。对于标准队列,根据队列流量和消息积压情况,传输中的消息限制为大约 120,000 条。如果您达到此限制,Amazon 会SQS返回一条OverLimit错误,表示在删除某些正在处理的消息之前,无法收到其他消息。对于FIFO队列,限制取决于活动的消息组。

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

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

要有效地管理机上消息,请执行以下操作:

  1. 提示删除-处理后删除消息(手动或自动),以减少正在处理的数量。

  2. 监控方式 CloudWatch — 设置飞行中计数过高的警报,以防止达到极限。

  3. 分配负载-如果您要处理大量消息,请使用额外的队列或使用者来平衡负载并避免瓶颈。

  4. 申请增加配额-如果需要更高的限额,请向 Su Amazon pp ort 提交申请。

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

在标准队列和FIFO(先进先出)队列中,可见性超时都有助于防止多个使用者同时处理同一条消息。但是,由于 Amazon 的 at-least-once交付模式SQS,无法绝对保证在可见性超时期间消息不会超过一次传送。

  • 标准队列-标准队列中的可见性超时会阻止多个使用者同时处理同一条消息。但是,由于 at-least-once传送模式的原因,Amazon SQS 不保证在可见性超时时间内不会多次传送一条消息。

  • FIFOq@@ u eues — 对于FIFO队列,具有相同消息组 ID 的消息将按严格的顺序处理。当带有消息组 ID 的消息处于传输中状态时,该组中的后续消息在删除或可见性超时到期后才可用。但是,这不会无限期 “锁定” 该群组——每条消息都是按顺序处理的,只有当每条消息被删除或再次可见时,该群组中的下一条消息才可供消费者使用。这种方法可确保在群组内进行有序处理,而不会不必要地阻止群组传送消息。

处理故障

如果由于应用程序错误、崩溃或连接问题,在可见性超时到期之前没有处理和删除消息,则消息将在队列中再次可见。然后,相同或不同的使用者可以检索它以进行另一次处理尝试。这样可以确保即使初始处理失败,消息也不会丢失。但是,将可见性超时设置得过高可能会延迟未处理消息的重新出现,从而可能减慢重试速度。根据预期的处理时间设置适当的可见性超时至关重要,这样才能及时处理消息。

更改和终止可见性超时

您可以使用以下ChangeMessageVisibility操作更改或终止可见性超时:

  • 更改超时-使用动态调整可见性超时ChangeMessageVisibility。这允许您延长或缩短超时持续时间以满足处理需求。

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

最佳实践

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

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

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

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