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

# Amazon SQS 消息处理和定时
<a name="best-practices-message-processing"></a>

本主题提供了有关优化 Amazon SQS 中消息处理速度和效率的全面指导，包括及时处理消息、选择最佳轮询模式以及配置长轮询以提高性能的策略。

****主题****
+ [在 Amazon SQS 中及时处理消息](best-practices-processing-messages-timely-manner.md)
+ [在 Amazon SQS 中设置长轮询](best-practices-setting-up-long-polling.md)
+ [在 Amazon SQS 中使用合适的轮询模式](best-practices-using-appropriate-polling-mode.md)

# 在 Amazon SQS 中及时处理消息
<a name="best-practices-processing-messages-timely-manner"></a>

可见性超时设置取决于您的应用程序需要多长时间来处理和删除消息。例如，如果您的应用程序处理一条消息需要花费 10 秒，并且您将可见性超时设置为 15 分钟，则在上一次处理尝试失败的情况下，您必须等待一个相对较长的时间才能再次尝试处理消息。或者，如果您的应用程序处理一条消息需要花费 10 秒，但您将可见性超时仅设置为 2 秒，则当原始使用者仍在处理消息时，另一个使用者会收到重复消息。

要确保有足够的时间处理消息，请使用下列策略之一：
+ 如果您知道（或者可以合理地估计）处理消息所需的时间，则将消息的*可见性超时* 延长至处理消息所需的最长时间并删除消息。有关更多信息，请参阅[配置可见性超时](sqs-visibility-timeout.md#configuring-visibility-timeout)。
+ 如果您不知道处理消息需要多长时间，请为您的使用者流程创建*检测信号*：指定初始可见性超时（例如 2 分钟），然后（只要您的使用者仍在处理该消息），就可以每分钟将可见性超时延长 2 分钟。
**重要**  
最大可见性超时为从 Amazon SQS 收到 `ReceiveMessage` 请求时起 12 小时。延长可见性超时不会重置 12 小时的最大值。  
此外，您可能无法将单个消息的超时时间设置为 `ReceiveMessage` 请求启动计时器后的整整 12 小时（即 43200 秒）。例如，如果您收到一条消息，并立即通过发送 `ChangeMessageVisibility` 调用，将 `VisibilityTimeout` 设置为 43200 秒，以设置 12 小时的最大值，则该消息很可能会失败。但是，除非通过 `ReceiveMessage` 请求消息和更新可见性超时之间存在明显的延迟，否则使用 43195 秒这个值会起到作用。如果您的使用者需要超过 12 小时，请考虑使用 Step Functions。

# 在 Amazon SQS 中设置长轮询
<a name="best-practices-setting-up-long-polling"></a>

当 `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` API 操作的等待时间大于 0 时，*长轮询*生效。最长长轮询等待时间为 20 秒。长轮询通过减少空响应（当`ReceiveMessage`请求没有消息可用时）和虚假空响应（当消息可用但未包含在响应中时）的数量来帮助降低使用 Amazon SQS 的成本。有关更多信息，请参阅 [Amazon SQS 短轮询和长轮询](sqs-short-and-long-polling.md)。

要确保最佳消息处理，请使用以下策略：
+ 在大多数情况下，您可以将 `ReceiveMessage` 等待时间设置为 20 秒。如果 20 秒对您的应用程序来说太长，则可设置较短的 `ReceiveMessage` 等待时间（最少 1 秒）。如果您不使用 AWS 软件开发工具包来访问 Amazon SQS，或者将 AWS 软件开发工具包配置为缩短等待时间，则可能需要修改您的 Amazon SQS 客户端，以允许更长的请求或使用更短的等待时间进行长时间轮询。
+ 如果您对多个队列实施长轮询，则对每个队列使用一个线程，而不是对所有队列使用单个线程。如果对每个队列使用一个线程，您的应用程序将能够在各队列中的消息可用时处理这些消息；如果使用单个线程来轮询多个队列，则可能导致应用程序在等待（最长 20 秒）没有任何可用消息的队列时无法处理其他队列中的可用消息。

**重要**  
为避免 HTTP 错误，请确保 `ReceiveMessage` 请求的 HTTP 响应超时比 `WaitTimeSeconds` 参数更长。有关更多信息，请参阅 [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)。

# 在 Amazon SQS 中使用合适的轮询模式
<a name="best-practices-using-appropriate-polling-mode"></a>
+ 长轮询使您能够在消息可用后立即从 Amazon SQS 队列中使用消息。
  + 要降低使用 Amazon SQS 的成本并减少空队列的空接收次数（对不返回任何消息的 `ReceiveMessage` 操作的响应次数），请启用长轮询。有关更多新信息，请参阅 [Amazon SQS 长轮询](sqs-short-and-long-polling.md)。
  + 要提高轮询具有多次接收的多个线程的效率，请减少线程数。
  + 在大多数情况下，长轮询优于短轮询。
+ 短轮询会立即返回响应，即使轮询的 Amazon SQS 队列为空。
  + 要满足应立即响应 `ReceiveMessage` 请求的应用程序的要求，请使用短轮询。
  + 短轮询的计费与长轮询相同。