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

aug*_*rar 5 polling amazon-sqs amazon-web-services long-polling

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

根据文件:

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

长轮询提供以下好处:

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

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

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

use*_*510 13

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

  • 何时需要立即处理消息.
  • 在单个线程中轮询多个队列时.

来自SQS 常见问题解答:

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

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

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

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

  • “当需要立即处理消息时”并不完全正确。它应该类似于“当对 ReceiveMessage 的调用必须立即返回时”。实际上,长轮询比短轮询更能立即处理消息。请注意 AWS 文档中引用的问题中的“消息可用后立即返回”。 (5认同)