Amazon SQS dead-letter queues - Amazon Simple Queue Service
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

如果我们为英文版本指南提供翻译,那么如果存在任何冲突,将以英文版本指南为准。在提供翻译时使用机器翻译。

Amazon SQS dead-letter queues

Amazon SQS 支持 dead-letter queues,其他队列(source queues)可以针对无法成功处理(已消耗)的消息进行目标。死信队列有助于调试您的应用程序或消息传递系统,因为它们可让您隔离有问题的消息以确定其处理失败的原因。有关创建队列并使用 Amazon SQS 控制台,参见 Configuring a dead-letter queue (console).

重要

将队列指定为源队列时,不会 自动创建死信队列。必须先创建标准或FIFO队列,然后才能将其指定为死信队列。

How do dead-letter queues work?

有时会因各种可能的问题 (例如,创建者应用程序或使用者应用程序内的错误条件或导致您的应用程序代码出现问题的意外状态更改) 而导致无法处理消息。例如,如果用户使用某特定产品 ID 下达 Web 订单,但产品 ID 已被删除,则 Web 商店的代码会失败并显示错误,而且包含订单请求的消息将发送到死信队列。

有时,创建器和使用器可能无法解释其用于通信的协议的各个方面,从而导致消息中断或丢失。此外,使用器的硬件错误可能会中断消息负载。

TheThethe redrive policy 指定 source queuedead-letter queue以及其下的条件 Amazon SQS 如果源队列的消费者未能处理指定的次数,则向后者移动来自前者的消息。当消息的 ReceiveCount 超出队列的 maxReceiveCount 时,Amazon SQS 会将该消息移到死信队列(带有其原始消息 ID)。例如,如果源队列的重新驱动策略已将 maxReceiveCount 设置为 5,并且源队列的使用器收到一条消息 6 次而从未将其删除,则 Amazon SQS 会将该消息移至死信队列。

要指定死字母队列,可以使用控制台或 AWS SDK for Java. 您必须为将消息发送到死信队列的每个队列执行此操作。同一类型的多个队列可将一个死信队列作为目标。有关更多信息,请参阅 CreateQueue SetQueueAttributes 操作的 Configuring a dead-letter queue (console)RedrivePolicy 属性。

重要

FIFO 队列的死信队列也必须是 FIFO 队列。同样,标准队列的死信队列也必须是标准队列。

您必须使用相同的 AWS 账户来创建死信队列以及向死信队列发送消息的其他队列。此外,死信队列必须驻留在使用死信队列的其他队列所在的区域中。例如,如果在美国东部(俄亥俄州)区域中创建一个队列,并且要对该队列使用死信队列,则第二个队列也必须位于美国东部(俄亥俄州)区域中。

消息的过期始终基于其原始排队时间戳。当邮件移动到死信队列时,排队时间戳保持不变。例如,如果消息在移动到死信队列之前在原始队列中花费了 1 天,并且死信队列的保留期设置为 4 天,则在 3 天后,邮件将从死信队列中删除。因此,最佳做法是始终将死信队列的保留期设置为长于原始队列的保留期。

What are the benefits of dead-letter queues?

死信队列的主要任务是处理消息失败。利用死信队列,您可以留出和隔离无法正确处理的消息以确定其处理失败的原因。设置死信队列可让您执行以下操作:

  • Configure an alarm for any messages delivered to a dead-letter queue.

  • Examine logs for exceptions that might have caused messages to be delivered to a dead-letter queue.

  • Analyze the contents of messages delivered to a dead-letter queue to diagnose software or the producer’s or consumer’s hardware issues.

  • Determine whether you have given your consumer sufficient time to process messages.

How do different queue types handle message failure?

Standard queues

标准队列 保持处理消息直到保留期到期为止。这可确保连续处理消息,从而最大程度地减小队列由无法处理的消息阻止的几率。它还可以确保快速恢复您的队列。

在一个处理数千条消息的系统中,拥有使用器反复无法确认和删除的大量消息可能会增加成本并给硬件带来额外负载。最好是在几次处理尝试之后将失败的消息移至死信队列,而不是在这些消息到期前一直尝试处理它们。

注意

标准队列允许大量机上消息。如果您的大多数消息无法使用且无法发送到死信队列,则处理有效消息的速率将下降。因此,要保持队列的效率,您必须确保应用程序正确处理消息。

FIFO queues

FIFO队列 通过从消息组中按顺序消耗消息确保完全一次处理。因此,尽管使用者可继续检索另一个消息组中的有序消息,但在阻止队列的消息得到成功处理之前,第一个消息组将保持不可用状态。

注意

FIFO队列允许更少数量的机上消息。因此,要确保您的 FIFO 队列不会被消息阻止,您必须确保应用程序正确处理消息。

When should I use a dead-letter queue?

DO使用带标准队列的死字母队列。当您的应用程序不依赖排序时,您应始终利用死信队列。死信队列可帮助您排查不正确的消息传输操作的问题。

注意

即使您使用死信队列,也应继续监控您的队列并重试发送因临时原因而失败的消息。

请使用死字母队列来减少消息数量,减少系统暴露于 poison-pill messages (可接收但无法处理的消息)。

当您希望能够无限期重试消息传输时,不要使用带标准队列的死字母队列。例如,如果您的程序必须等待某个依赖过程变得有效或可用,请不要使用死信队列。

如果不希望解决消息或操作的确切顺序,请勿使用FIFO队列中的盲字队列。例如,请不要对视频编辑套件的编辑决策列表 (EDL) 中的指令使用死信队列,此情况下,更改编辑的顺序将更改后续编辑的上下文。

Troubleshooting dead-letter queues

在某些情况下,Amazon SQS 死信队列的行为可能并不总是符合预期。此部分概述了常见问题并说明如何解决这些问题。

Viewing messages using the console might cause messages to be moved to a dead-letter queue

Amazon SQS 在控制台中查看对应队列的重新驱动策略的消息的计数。因此,如果在控制台中查看了对应队列的重新驱动器策略中指定的次数,则消息将移至对应队列的死字母队列。

要调整此行为,您可以执行下列操作之一:

  • Increase the Maximum Receives setting for the corresponding queue's redrive policy.

  • Avoid viewing the corresponding queue's messages in the console.

The NumberOfMessagesSent and NumberOfMessagesReceived for a dead-letter queue don't match

如果您手动向死信队列发送消息,它将由 NumberOfMessagesSent 指标捕获。不过,如果因处理尝试失败而发送消息到死信队列,则此指标不会捕获该消息。因此,NumberOfMessagesSentNumberOfMessagesReceived 的值可能不同。