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

# Amazon SQS 错误处理和有问题的消息
<a name="best-practices-error-handling"></a>

本主题提供有关管理和缓解 Amazon SQS 中的错误的详细说明，包括处理请求错误、捕获有问题的消息以及配置死信队列保留时间以确保消息可靠性的技术。

****主题****
+ [处理 Amazon SQS 中的请求错误](handling-request-errors.md)
+ [捕获 Amazon SQS 中有问题的消息](capturing-problematic-messages.md)
+ [在 Amazon SQS 中设置死信队列保留时间](setting-up-dead-letter-queue-retention.md)

# 处理 Amazon SQS 中的请求错误
<a name="handling-request-errors"></a>

要处理请求错误，请使用下列策略之一：
+ 如果您使用 AWS SDK，则已经有自动*重试和退避逻辑可供*您使用。有关更多信息，请参阅《Amazon Web Services 一般参考》**中的 [AWS中的错误重试和指数回退](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)。
+ 如果您不使用 AWS 软件开发工具包功能进行重试和退避，则在未收到来自 Amazon SQS 的消息、超时或错误消息后，请允许暂停（例如 200 毫秒），然后重试[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)操作。对于将产生相同结果的 `ReceiveMessage` 的后续使用，应允许更长的暂停时间（例如 400 毫秒）。

# 捕获 Amazon SQS 中有问题的消息
<a name="capturing-problematic-messages"></a>

要捕获所有无法处理的消息并收集准确的 CloudWatch 指标，请配置[死信队列](sqs-dead-letter-queues.md)。
+ 在源队列无法将消息处理指定次数后，重新驱动策略会将消息重定向到死信队列。
+ 使用死信队列将减少消息数并减小向您公开*毒丸*消息（可接收但无法处理的消息）的几率。
+ 在队列中加入毒丸消息可能会给出错误的毒丸消息的年龄，从而扭曲[`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch 指标。配置死信队列有助于避免在使用此指标时发出错误警报。

# 在 Amazon SQS 中设置死信队列保留时间
<a name="setting-up-dead-letter-queue-retention"></a>

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

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