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

# 在 Amazon SQS 中使用死信队列
<a name="sqs-dead-letter-queues"></a>

Amazon SQS 支持死信队列 (DLQs)，对于未成功处理的消息，源队列可以将死信队列作为目标。 DLQs 对于调试应用程序很有用，因为您可以隔离未使用的消息以确定处理失败的原因。为了获得最佳性能，最佳实践是将源队列和死信队列保持在同一个 AWS 账户 和区域内。消息进入死信队列后，您可以：
+ 查看日志，以了解可能导致消息移动到死信队列的异常。
+ 分析移动到死信队列的消息内容，以诊断应用程序问题。
+ 确定是否为使用者提供了充足的时间来处理消息。
+ 使用[死信队列重新驱动](sqs-configure-dead-letter-queue.md)将消息移出死信队列。

您必须先创建一个新队列，然后才能将其配置为死信队列。有关使用 Amazon SQS 控制台配置死信队列的信息，请参阅[使用 Amazon SQS 控制台配置死信队列](sqs-configure-dead-letter-queue.md)。要获得死信队列方面的帮助，例如如何为移动到死信队列的任何消息配置警报，请参阅[使用 Amazon 为死信队列创建警报 CloudWatch](dead-letter-queues-alarms-cloudwatch.md)。

**注意**  
如果不想中断消息或操作的准确顺序，请不要对 FIFO 队列使用死信队列。例如，请不要对视频编辑套件的编辑决策列表 (EDL) 中的指令使用死信队列，此情况下，更改编辑的顺序将更改后续编辑的上下文。

## 使用死信队列策略
<a name="policies-for-dead-letter-queues"></a>

使用**重新驱动策略**指定 `maxReceiveCount`。`maxReceiveCount` 是使用者可以从源队列接收消息的次数，超过该次数后，消息会被移动到死信队列。例如，如果将 `maxReceiveCount` 设置为较低的值（例如 1），那么只要接收消息失败一次，该消息就会被直接移动到死信队列。要确保您的系统能够抵御错误，请将 `maxReceiveCount` 设置得足够高，以允许足够的重试。

对于采用大`maxReceiveCount`于 3 的重新驱动策略的标准队列，如果一条消息被接收 3 次或更多次但未被删除，则 SQS 会将其移到队列的后面。然后，该`ApproximateAgeOfOldestMessage`指标会反映下一封未超过此阈值的消息的存在时间。

**重新驱动允许策略**指定哪些源队列可以访问死信队列。您可以选择允许所有源队列使用死信队列、允许特定的源队列使用死信队列或拒绝所有源队列使用死信队列。默认设置是允许所有源队列使用死信队列。如果您选择允许特定队列使用 `byQueue` 选项，则可以使用源队列 Amazon 资源名称（ARN）指定最多 10 个源队列。如果您指定 `denyAll`，则队列不能用作死信队列。

## 了解死信队列的消息保留期
<a name="understanding-message-retention-periods"></a>

对于标准队列，消息的到期时间始终基于其原始入队时间戳。将消息移至死信队列时，入队时间戳保持不变。`ApproximateAgeOfOldestMessage` 指标指示消息何时移入死信队列，而不是消息最初发送的时间。例如，假设一条消息在原始队列中停留了 1 天，然后才移至死信队列。如果死信队列的保留期为 4 天，则消息将在 3 天后从死信队列中删除，且 `ApproximateAgeOfOldestMessage` 为 3 天。因此，最佳实践是始终将死信队列的保留期设置为比原始队列的保留期长。

对于 FIFO 队列，当消息移到死信队列时，入队时间戳会重置。`ApproximateAgeOfOldestMessage` 指标指示消息何时移动到死信队列。在上面的同一个示例中，消息在 4 天后从死信队列中删除，且 `ApproximateAgeOfOldestMessage` 为 4 天。