SQS短期投票是否比长期投票更可取？

Amazon SQS支持两种可用消息轮询模式:短轮询和长轮询.使用长轮询时,使用者指定等待可用消息的超时为1-20秒.

根据文件:

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

长轮询提供以下好处:

通过允许Amazon SQS在发送响应之前等待队列中的消息可用来消除空响应.除非连接超时,否则对ReceiveMessage请求的响应至少包含一条可用消息,最多为ReceiveMessage操作中指定的最大消息数.

通过查询所有 - 而不是亚马逊SQS服务器的子集来消除错误的空响应.

一旦可用,就立即返回消息.

上述特征使长期民意调查看起来相当不错.那么有一个使用短轮询更好的用例吗？

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

短轮询几乎总是优于长轮询.以下是两个可能需要短轮询的用例(在SQS常见问题解答中给出):

何时需要立即处理消息.

在单个线程中轮询多个队列时.

来自SQS 常见问题解答:

在几乎所有情况下,亚马逊SQS长轮询比短轮询更可取.长轮询请求让您的队列使用者一旦到达您的队列就会收到消息,同时减少返回的空ReceiveMessageResponse实例的数量.

亚马逊SQS长轮询在大多数用例中以更低的成本获得更高的性能.但是,如果您的应用程序期望从ReceiveMessage调用立即响应,则可能无法在不对应用程序进行某些修改的情况下利用长轮询.

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

在这样的应用程序中,最好使用单个线程来处理一个队列,从而允许应用程序利用Amazon SQS长轮询提供的好处.