SQS 短轮询是不是比长轮询更可取？

Posted 2023-02-18

【中文标题】SQS 短轮询是不是比长轮询更可取？

【英文标题】：Is SQS short polling ever preferable to long polling?SQS 短轮询是否比长轮询更可取？

【发布时间】：2018-12-30 17:42:02

【问题描述】：

Amazon SQS 支持两种可用消息的轮询模式：短轮询和长轮询。对于长轮询，消费者指定 1-20 秒的超时时间来等待可用消息。

根据documentation：

默认情况下，Amazon SQS 使用 短轮询，仅查询其服务器的子集（基于加权随机分布），以确定是否有任何消息可用于响应。

长轮询提供以下好处：

通过允许 Amazon SQS 在发送响应之前等待队列中可用的消息来消除空响应。除非连接超时，否则对 ReceiveMessage 请求的响应至少包含一条可用消息，最多为 ReceiveMessage 操作中指定的最大消息数。 通过查询所有（而不是部分）Amazon SQS 服务器来消除错误的空响应。 在消息可用时立即返回。

以上特点让长轮询看起来相当不错。那么是否存在更可取短轮询的用例？

特别是对于高吞吐量队列，短轮询比长轮询更快吗？

【参考方案1】：

长轮询几乎总是比短轮询更可取。以下是两个可能需要短轮询的用例（在 SQS 常见问题解答中给出）：

需要即时消息处理时。 当您在单个线程中轮询多个队列时。

来自 SQS FAQs:

在几乎所有情况下，Amazon SQS 长轮询优于短轮询 轮询。 长轮询请求让您的队列消费者接收 消息一到达您的队列，同时减少 返回的空 ReceiveMessageResponse 实例数。

Amazon SQS 长轮询以更低的成本提高性能 在大多数用例中。但是，如果您的应用程序需要 ReceiveMessage 调用的立即响应，您可能无法 利用长轮询而不对您的 应用程序。

例如，如果您的应用程序使用单个线程来轮询多个 队列，从短轮询切换到长轮询可能不会 工作，因为单线程将等待长轮询超时 任何空队列，延迟任何可能的队列的处理 包含消息。

在这样的应用程序中，最好使用单线程 只处理一个队列，允许应用程序利用 Amazon SQS 长轮询提供的好处。

【讨论】：

“当需要即时消息处理时”不太正确。它应该类似于“当对 ReceiveMessage 的调用必须立即返回时”。长轮询实际上允许比短轮询更直接地处理消息。请注意引用 AWS 文档的问题中的“一旦可用就返回消息”。