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