amazon-web-services - SQS短轮询是否比长轮询更可取？

Question

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

根据documentation：


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





长时间轮询具有以下优点：


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



以上特征使长轮询看起来相当不错。那么，有没有使用短轮询更好的用例？

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

Answer 1

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


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


从SQS FAQs：


在几乎所有情况下，Amazon SQS长轮询比短轮询更可取
轮询。长轮询请求可让您的队列使用者接收
邮件一到达您的队列，同时减少了
返回的空ReceiveMessageResponse实例数。

Amazon SQS长期轮询可降低成本，提高性能
在大多数用例中。但是，如果您的应用程序期望
来自ReceiveMessage调用的即时响应，您可能无法
充分利用长时间轮询而无需对您的内容进行一些修改
应用。

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

在这样的应用程序中，使用单线程是一个好习惯
仅处理一个队列，从而允许应用程序利用
SQS长期轮询提供的好处。