本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
在 Amazon SQS 中使用死信队列
Amazon SQS 支持死信队列 (DLQ)，对于未成功处理的消息，源队列可以将死信队列作为目标。DLQ 对于调试应用程序非常有用，因为您可以隔离未使用的消息以确定处理失败的原因。为了获得最佳性能，最佳做法是将源队列和 DLQ 保持在相同 Amazon Web Services 账户 和区域内。消息进入死信队列后，您可以：
-
查看日志，以了解可能导致消息移动到死信队列的异常。
-
分析移至死信队列的消息的内容以诊断应用程序问题。
-
确定是否为使用者提供了充足的时间来处理消息。
-
使用死信队列重新驱动将消息移出死信队列。
在将其配置为死信队列之前，必须先创建一个新队列。有关使用 Amazon SQS 控制台配置死信队列的信息，请参阅了解如何使用 Amazon SQS 控制台配置死信队列。有关死信队列的帮助，例如如何为移至死信队列的所有消息配置警报，请参阅。使用 Amazon 为死信队列创建警报 CloudWatch
对死信队列使用策略
使用重新驱动策略指定. maxReceiveCount maxReceiveCount是指在消息移至死信队列之前，消费者可以从源队列接收消息的次数。例如，如果设置maxReceiveCount为较低的值（例如 1），则一次未能收到消息就会导致消息移至死信队列。要确保您的系统能够抵御错误，请将 maxReceiveCount 设置得足够高，以允许足够的重试。
重新驱动允许策略指定哪些源队列可以访问死信队列。您可以选择是允许所有源队列、允许特定的源队列还是拒绝所有源队列使用死信队列。默认设置允许所有源队列使用死信队列。如果您选择使用byQueue选项允许特定队列，则可以使用源队列 Amazon 资源名称 (ARN) 指定最多 10 个源队列。如果您指定 denyAll，则队列不能用作死信队列。
了解死信队列的消息保留期
对于标准队列，消息的到期时间始终基于其原始入队时间戳。将消息移至死信队列时，入队时间戳保持不变。该ApproximateAgeOfOldestMessage指标指示消息何时移入死信队列，而不是消息最初发送的时间。例如，假设一条消息在原始队列中停留了 1 天，然后才移至死信队列。如果死信队列的保留期为 4 天，则消息将在 3 天后从死信队列中删除，且 ApproximateAgeOfOldestMessage 为 3 天。因此，最佳实践是始终将死信队列的保留期设置为比原始队列的保留期长。
对于 FIFO 队列，当消息移到死信队列时，入队时间戳会重置。ApproximateAgeOfOldestMessage 指标指示消息何时移动到死信队列。在上面的同一个示例中，消息在 4 天后从死信队列中删除，且 ApproximateAgeOfOldestMessage 为 4 天。