Amazon Simple Queue Service
开发人员指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。点 击 Getting Started with Amazon AWS to see specific differences applicable to the China (Beijing) Region.

一般建议

下列准则可帮助您使用 Amazon SQS 降低成本并高效地处理消息。

处理消息

  • 要确保有足够的时间处理消息,您应使用下列策略之一:

    • 如果您知道 (或者可以合理地估计) 处理消息所需的时间,则将消息的可见性超时 延长至处理消息所需的最长时间并删除消息。有关更多信息,请参阅配置可见性超时更改消息的可见性超时

    • 如果您不知道处理消息所需的时间,请指定初始可见性超时(例如 2 分钟)和时段(在此时段后,您可以检查是否已处理消息)(例如 1 分钟)。如果消息未得到处理,请延长可见性超时 (例如,延长至 3 分钟)。

    注意

    如果您需要将可见性超时延长至最多 12 小时,请考虑使用 Amazon Simple Workflow Service

  • 要处理错误请求,您应使用下列策略之一:

    • 如果您使用 AWS 开发工具包,则已经可以任意使用自动重试和回退 逻辑。有关更多信息,请参阅 Amazon Web Services 一般参考 中的 AWS 中的错误重试和指数回退

    • 如果您未使用 AWS 开发工具包功能进行重试和回退,则在未收到任何消息、收到超时或收到来自 Amazon SQS 的错误消息的情况下重试 ReceiveMessage 操作之前,应允许暂停 (例如,200 毫秒)。对于将产生相同结果的 ReceiveMessage 的后续使用,应允许更长的暂停时间 (例如 400 毫秒)。

  • 要捕获所有无法处理的消息,并确保 CloudWatch 指标正确,您应配置死信队列

    • 在源队列无法将消息处理指定次数后,重新驱动策略会将消息重定向到死信队列。

    • 使用死信队列将减少消息数并减小向您公开毒丸消息 (可接收但无法处理的消息) 的几率。

    • 在队列中包含毒丸消息可能导致 ApproximateAgeOfOldestMessage CloudWatch 指标失真,因为它会提供不正确的毒丸消息存在时间。配置死信队列有助于避免在使用此指标时发出错误警报。

  • 在配置死信队列时,避免以下情况:标准 队列的消息处理不一致以及将最大接收次数设置为 1。

    重要

    在某些不常发生的场景中,如果您将最大接收次数设置为 1,则不管何时 ReceiveMessage 调用失败,消息都可能不被接收而移动到死信队列中。

降低成本

  • 要降低成本,可批处理您的消息操作:

    • 要发送、接收和删除消息,并通过单一操作更改多条消息的消息可见性超时,请使用 Amazon SQS 批处理 API 操作

    • 要将客户端缓冲和请求批处理合并,请将长轮询与 AWS SDK for Java附带的缓冲的异步客户端结合使用。

      注意

      Amazon SQS 缓冲的异步客户端当前不支持 FIFO 队列。

  • 要利用其他可能降低成本的或近乎瞬时的响应,请使用下列轮询模式之一:

    • 长轮询使您能够在消息可用后立即从 Amazon SQS 队列中使用消息。

      • 要降低使用 Amazon SQS 的成本并减少空队列的空接收次数 (对不返回任何消息的 ReceiveMessage 操作的响应次数),请启用长轮询。有关更多信息,请参阅 Amazon SQS 长轮询

      • 要提高轮询具有多次接收的多个线程的效率,请减少线程数。

      • 在大多数情况下,长轮询优于短轮询。

    • 短轮询会立即返回响应,即使轮询的 Amazon SQS 队列为空。

      • 要满足应立即响应 ReceiveMessage 请求的应用程序的要求,请使用短轮询。

      • 短轮询的计费与长轮询相同。

从标准队列移至 FIFO 队列

  • 如果您未对每条消息设置 DelaySeconds 参数,则可通过提供每条已发送消息的消息组 ID 来移动到 FIFO 队列。有关更多信息,请参阅 从标准队列移至 FIFO 队列