SQS队列/可见性超时/消息组

时间:2019-03-20 05:48:28

标签: amazon-web-services amazon-sqs

我是AWS的新手。我想在这里了解SQS。我也参加了一些培训,但是在论坛上仍然找不到答案。我在这里重申我的问题。请注意,我知道以下几个问题有明显的答案,因此更多是夸夸其谈。我之所以感到困惑,是因为我目前对这个话题的理解使我对后续的问题给出了矛盾的答案,这些后续问题在显而易见的已知问题之后出现在我的脑海中,并且剥夺了我认为可以理解的一切的信心。 / p>

如果我有一个名为 MyQueue Standard 队列,并且有100条消息,并且有2个完全独立的应用程序(作为使用者,请注意,它们不是使用者组)像您在Kafka中一样的应用程序;相反,它们是该队列的2个单独的应用程序),那么消费者可能会收到

(i)乱序消息和

(ii)邮件的多个副本

我的两个应用程序都不需要理会消息的顺序。但是出于问题的考虑,可以说我们有一个完美的投递顺序,没有多份副本,也没有网络问题,如果每条消息都在“可见性超时”窗口内,则两个使用者都可以完成处理。

问题1::这两个应用程序将分别收到100条消息,还是不会将提供给一个消费者的消息永远传递给另一个消费者?如果后者是正确的(没有网络问题,无序交付,多次交付),则:

  1. SNS-SQS是否能确保由多个使用者处理同一条消息?
  2. 使用者是否应该在处理后从队列中删除消息?因此,如果消息被处理器拾取,并且在处理发生时进入可见性超时,然后即使在可见性超时之前完成处理,消费者也仍未删除该消息,那么它将该消息再次出现,以供其他消费者使用?如果是这样,那么同样的事情也不适用于FIFO队列吗?

其他问题:

第二季度:可见性超时是否同时适用于标准队列和FIFO队列?如果它也适用于承诺仅发送一次的FIFO队列,那么,如果可见性超时出现在使用者结束处理消息之前,则它重新出现在队列中仅再次发送,从而至少返回一次处理。有人可以确认吗?

问题3::FIFO队列中有多个消息组?他们喜欢队列的分区吗?

2 个答案:

答案 0 :(得分:2)

问:两个应用程序都分别收到100条消息吗?

使用者每个API调用最多可以请求10条消息。这些将变为“不可见”,并且将提供给其他消费者。 (嗯,实际上有很小的可能会向多个消费者提供一条消息。这种情况很少见,但是有可能发生。如果这对您的用例不利,那么您应该跟踪数据库中的邮件,以确保每个邮件仅被处理一次。)

问:SNS-SQS是否扇出了确保多个消费者处理相同消息的方法?

想让“多个消费者”使用一条消息是很奇怪的。通常的愿望是处理每个消息一次。如果确实希望由多个使用者处理一条消息,则可以,可以将该消息发送到SNS,后者再将其发送到多个队列。

问:消费者是否应该在处理后从队列中删除消息?

是的。 Amazon SQS不知道何时处理消息。消费者必须通过收到消息时提供的ReceiptHandle删除消息。如果消息超时并且另一个使用者接收到该消息,则SQS将提供一个不同的ReceiptHandle,以便它知道哪个进程请求删除。

这也适用于FIFO队列。

问:可见性超时是否同时适用于标准队列和FIFO队列?

是的。如果可见性超时到期,则将消息提供给其他使用者。 “一次准确传递”避免了在标准队列可能中多次提供一条消息时出现的上述罕见情况。但是,如果可见性超时,即使在FIFO队列中,可见性也会再次在队列中可见。

问:FIFO队列中有多个消息组?他们喜欢队列的分区吗?

邮件组是对必须按顺序传递的邮件进行分组的一种方式。

假设有两个消息组AB,它们以以下顺序发送消息:A1B1A2,{ {1}}

即使尚未删除B2,也可以提供消息B1。但是,在删除A1之前将不会提供消息A2。将它们视为“迷你队列”。这样一来,许多邮件的处理都是无关的,而不必等待所有 all 先前的邮件被删除。

请参阅:Using the Amazon SQS Message Group ID - Amazon Simple Queue Service

答案 1 :(得分:1)

  

问题1:两个应用程序将分别收到100条消息,还是不会将提供给一个消费者的消息永远传递给另一个消费者?

这些都不是很准确。

标准队列永远不会有意地多次传递消息。 可能可能偶尔不止一次地传递消息-但这是例外,这是SQS是分布式系统并且可能出现情况的事实例如,队列中有一条消息存储在多个副本中,并且由于内部故障,并非所有副本都知道该消息。

如果一条消息被无意间传递了多次,则该消息可能会发给多个消费者或同一消费者。到SQS的使用者“连接”实际上是无状态的,每次传递消息列表时都会重置,因此SQS并不知道将每个消息传递给哪个使用者。

消费者在处理后删除他们的消息,否则他们的可见性超时将过期,并且一次又一次地传递给收件人–运气好的人每次都会传递给哪个消费者。如前所述,SQS没有消费者身份或状态的概念。 (在大容量应用程序中,单个使用者实际上可能与SQS具有多个连接,所有接收者都是并行接收消息,因为否则,网络往返行程和接收/删除周期会限制单个使用者每秒几百条消息。这些连接使用异步I / O,线程等进行处理,对于SQS而言并不重要,SQS不在乎给定连接上的哪个使用者。)

如果要将所有消息发送给所有使用者,则需要从SNS扇出到SQS。

  

第二季度:可见性超时是否同时适用于标准队列和FIFO队列?

是的。因为(如上所述)与SQS的连接不是持久的有状态连接,所以SQS使用可见性超时作为指示方,表明使用者丢失了消息或不正常地失败了,因此需要再次使消息可访问。 (死信队列阻止了这种情况的无休止地发生,将消息移到另一个队列中,因为重复的失败表明消费者有问题,或者是“毒丸”消息。)

在这里,

FIFO队列保留有序交付,您可能会争辩说它们恢复为“至少一次”交付,但想法是永远不要发生这种情况。如果是这样,则您的可见性超时太短,或者您的使用者崩溃或以其他方式放错了消息。

  

第三季度:什么是FIFO队列中的多个消息组?

消息组允许FIFO队列支持对组消息的有序,并行处理,这些消息之间的排序跨组边界彼此无关无关紧要。邮件在每个组中按顺序传递。

如果是FIFO队列,如果所有消息都使用相同的组ID发送,则一次只能使用一个使用者。

按顺序传递(简单说明)表示,直到消费者接收到消息1并将其删除(完成)后,消息2才会传递给任何消费者。为了使交付包括所有处理(不仅仅是初始的“交付”)。或者,如果队列中的20条消息具有相同的组ID,并且两个使用者各自请求10条消息,则一个使用者获得10条消息,而另一方则什么也没得到-因为-这第二条10条消息必须隔离,直到前10条消息被隔离为止已处理(否则我们将不再“按顺序”)。

在20条消息的情况下,如果A组中有14个人,B组中有6个人,则一个消费者将收到A1-A10,A11-A14将被隔离,直到A1-A10完成,但是当第一个消费者忙时,另一个消费者可能同时拥有B1-B6。

再次注意,没有消费者亲和力。如果同时删除A1-A10和B1-B6,则下一个A11-A14将交付给一个消费者,但不一定是处理A1-A10的消费者。