SQS 队列/可见性超时/消息组
SQS Queues/ Visibility Timeouts/ message groups
我是 AWS 新手。我想在这里了解 SQS。我也参加了一些培训，但我仍然无法在论坛中得到一些答案。我在这里重申我的问题。请注意，我知道下面的几个问题有明显的答案，因此更像是一种修辞。我的困惑源于这样一个事实，即我目前对该主题的理解导致我对后续问题给出了相互矛盾的答案，这些问题 spring 在我脑海中浮现出明显的已知问题，并带走了我认为我认为的任何东西的信心明白了。
如果我有一个名为 MyQueue 的 Standard 队列并且有 100 条消息，并且如果有 2 个完全独立的应用程序（作为消费者; 请注意，它们不是像您在 Kafka 中那样的相同应用程序的消费者组；相反，它们是此队列的 2 个独立应用程序），那么消费者可能会收到
(i) 乱序消息和
(ii) 消息的多个副本
我的两个应用程序都不需要关心消息的顺序。但是为了这个问题，假设我们有一个完美的交付顺序，没有多个副本，也没有网络问题，并且如果每条消息都在可见性超时 window.
内，两个消费者都会完成他们的处理。
Q1： 这两个应用程序是否会分别收到 100 条消息，或者一个消费者可以使用的消息永远不会传递给另一个消费者？如果是后者（没有网络问题、无序交付、多次交付），则：
- SNS-SQS fanout 是保证同一条消息被多个消费者处理的方式吗？
- 消费者是否应该在处理后从队列中删除消息？因此，如果消息被处理器拾取，并且在处理发生时进入可见性超时，然后 not 被消费者删除，即使在可见性超时之前处理完成，那么该消息是否会返回供其他消费者使用？如果是这样，那么同样的事情不会也适用于 FIFO 队列吗？
其他问题：
Q2:Visibility timeout是否适用于Standard Queue和FIFO Queue？如果它也适用于承诺exactly once delivery的FIFO Queue，那么，如果在consumer结束处理消息之前出现Visibility Timeout，那么它会重新出现在队列中只是为了再次传递从而回到至少一次处理。有人可以确认吗？
问题 3:什么是 FIFO 队列中的多个消息组？它们像队列的分区吗？
问：这两个应用程序会各自收到 100 条消息吗？
消费者每次 API 调用最多可以请求 10 条消息。这些将变为 'invisible' 并且 不会 提供给其他消费者。 （好吧，实际上 是 一条消息可能会提供给多个消费者的可能性很小。这种情况很少见，但它可能会发生。如果这对您的用例不利，那么您应该跟踪数据库中的消息以确保它们每条只被处理一次。）
问：SNS-SQS fanout 是保证同一条消息被多个消费者处理的方式吗？
想要单个消息被'multiple consumers'消费是很奇怪的。通常的愿望是处理每条消息一次。如果您确实希望消息由多个消费者处理，那么，是的，您可以将消息发送到 SNS，然后 SNS 可以将其发送到多个队列。
问：消费者处理完消息后是否应该从队列中删除？
是的。 Amazon SQS 不知道消息何时被处理。消费者必须通过收到消息时提供的 ReceiptHandle 删除消息。如果消息超时并且另一个消费者收到它，SQS 将提供一个不同的 ReceiptHandle，以便它知道哪个进程请求删除。
这也适用于 FIFO 队列。
问：可见性超时是否适用于标准队列和先进先出队列？
是的。如果可见性超时到期，消息将提供给另一个消费者。 "exactly once delivery" 避免了上述罕见情况，即标准队列 中的一条消息可能 被多次提供。但是，如果可见性超时，即使在 FIFO 队列中，它也会有意再次在队列中可见。
问：什么是 FIFO 队列中的多个消息组？它们像队列的分区吗？
邮件组是一种对必须按顺序传递的邮件进行分组的方式。
假设有两个消息组，A和B，它们按以下顺序发送消息：A1、B1、A2 , B2
即使 A1 尚未删除，也可以提供消息 B1。但是，在删除 A1 之前，将 不会 提供消息 A2。将它们视为 'mini-queues'。这允许处理大量不相关的消息，而不必等待 所有 之前的消息被删除。
参见：Using the Amazon SQS Message Group ID - Amazon Simple Queue Service
Q1: Will both the applications individually receive 100 messages each or will a message that is made available to one consumer won't ever be delivered to the other consumer?
这些都不太准确。
标准队列永远不会故意多次传递一条消息。 可能消息可能偶尔被传递不止一次——但这是例外情况，是 SQS 是一个分布式系统和情况可能会出现，例如，队列将一条消息存储在多个副本中，并且由于内部故障，所有副本都不知道一条消息。
如果一条消息被无意中发送了不止一次，它可能发送给多个消费者或同一个消费者。 SQS 的消费者 "connections" 实际上是无状态的，每次传递消息列表时都会重置，因此 SQS 不知道它向哪个消费者传递了每条消息。
消费者在处理后删除他们的消息，否则他们的可见性超时将过期并且它们会被一次又一次地发送——每次都发送给幸运的消费者。如前所述，SQS 没有消费者身份或状态的概念。 （在大容量应用程序中，单个消费者实际上可能有多个到 SQS 的连接，所有连接都并行接收消息，因为网络往返和 receive/delete 的周期否则会将单个消费者限制为每秒几百条消息. 这些连接是否使用异步 I/O、线程等处理，对 SQS 来说并不重要，它不关心给定连接上有哪个消费者。）
如果要将所有消息发送给所有消费者，则需要从 SNS 到 SQS 的扇出。
Q2: Is the Visibility timeout applicable to both Standard Queue and FIFO Queue?
是的。因为（如上所述）与 SQS 的连接不是持久的、有状态的连接，SQS 使用可见性超时作为消费者丢失消息或非正常失败的指示，因此需要再次使消息可访问。 （死信队列防止这种情况无休止地发生，将消息移动到不同的队列，因为重复的失败表明消费者或 "poison pill" 消息有问题。）
FIFO 队列在此处保留按顺序交付，您可能会争辩说它们恢复为 "at least once" 交付，但我们的想法是这永远不会发生。如果是这样，那么您的可见性超时太短，或者您的消费者崩溃或以其他方式错放消息。
Q3: What are multiple message Groups within a FIFO Queue?
消息组允许 FIFO 队列支持按顺序并行处理组消息，这些消息的排序相对于跨组边界 无关紧要。消息在每个组内按顺序传递。
如果是先进先出队列，如果所有消息都使用相同的组ID发送，那么一次只能有一个消费者在工作。
按顺序传递（简单说明）意味着消息 2 不会传递给任何消费者，直到消息 1 已被消费者接收并删除（完成）。为了交付包括所有处理（不仅仅是初始"delivery"）。或者，如果队列中的 20 条消息具有相同的组 ID，并且两个消费者各请求 10 条消息，则一个消费者获得 10 条消息，而另一个则什么也得不到——但是——因为必须隔离后 10 条消息，直到前 10 条消息被隔离已处理（否则我们不再是 "in order"）。
在20条消息的场景下，如果14条在A组，6条在B组，一个消费者会收到A1-A10，A11-A14会被隔离，直到A1-A10完成，但是第一个消费者忙，另一个消费者可以同时拥有B1-B6。
再次注意，没有消费者亲和力。如果同时删除 A1-A10 和 B1-B6，则 A11-A14 接下来将交付给 one 消费者，但不一定是处理 A1-A10 的消费者。
我是 AWS 新手。我想在这里了解 SQS。我也参加了一些培训，但我仍然无法在论坛中得到一些答案。我在这里重申我的问题。请注意，我知道下面的几个问题有明显的答案，因此更像是一种修辞。我的困惑源于这样一个事实，即我目前对该主题的理解导致我对后续问题给出了相互矛盾的答案，这些问题 spring 在我脑海中浮现出明显的已知问题，并带走了我认为我认为的任何东西的信心明白了。
如果我有一个名为 MyQueue 的 Standard 队列并且有 100 条消息，并且如果有 2 个完全独立的应用程序（作为消费者; 请注意，它们不是像您在 Kafka 中那样的相同应用程序的消费者组；相反，它们是此队列的 2 个独立应用程序），那么消费者可能会收到
(i) 乱序消息和
(ii) 消息的多个副本
我的两个应用程序都不需要关心消息的顺序。但是为了这个问题，假设我们有一个完美的交付顺序，没有多个副本，也没有网络问题，并且如果每条消息都在可见性超时 window.
内，两个消费者都会完成他们的处理。Q1： 这两个应用程序是否会分别收到 100 条消息，或者一个消费者可以使用的消息永远不会传递给另一个消费者？如果是后者（没有网络问题、无序交付、多次交付），则：
- SNS-SQS fanout 是保证同一条消息被多个消费者处理的方式吗？
- 消费者是否应该在处理后从队列中删除消息？因此，如果消息被处理器拾取，并且在处理发生时进入可见性超时，然后 not 被消费者删除，即使在可见性超时之前处理完成，那么该消息是否会返回供其他消费者使用？如果是这样，那么同样的事情不会也适用于 FIFO 队列吗？
其他问题：
Q2:Visibility timeout是否适用于Standard Queue和FIFO Queue？如果它也适用于承诺exactly once delivery的FIFO Queue，那么，如果在consumer结束处理消息之前出现Visibility Timeout，那么它会重新出现在队列中只是为了再次传递从而回到至少一次处理。有人可以确认吗？
问题 3:什么是 FIFO 队列中的多个消息组？它们像队列的分区吗？
问：这两个应用程序会各自收到 100 条消息吗？
消费者每次 API 调用最多可以请求 10 条消息。这些将变为 'invisible' 并且 不会 提供给其他消费者。 （好吧，实际上 是 一条消息可能会提供给多个消费者的可能性很小。这种情况很少见，但它可能会发生。如果这对您的用例不利，那么您应该跟踪数据库中的消息以确保它们每条只被处理一次。）
问：SNS-SQS fanout 是保证同一条消息被多个消费者处理的方式吗？
想要单个消息被'multiple consumers'消费是很奇怪的。通常的愿望是处理每条消息一次。如果您确实希望消息由多个消费者处理，那么，是的，您可以将消息发送到 SNS，然后 SNS 可以将其发送到多个队列。
问：消费者处理完消息后是否应该从队列中删除？
是的。 Amazon SQS 不知道消息何时被处理。消费者必须通过收到消息时提供的 ReceiptHandle 删除消息。如果消息超时并且另一个消费者收到它，SQS 将提供一个不同的 ReceiptHandle，以便它知道哪个进程请求删除。
这也适用于 FIFO 队列。
问：可见性超时是否适用于标准队列和先进先出队列？
是的。如果可见性超时到期，消息将提供给另一个消费者。 "exactly once delivery" 避免了上述罕见情况，即标准队列 中的一条消息可能 被多次提供。但是，如果可见性超时，即使在 FIFO 队列中，它也会有意再次在队列中可见。
问：什么是 FIFO 队列中的多个消息组？它们像队列的分区吗？
邮件组是一种对必须按顺序传递的邮件进行分组的方式。
假设有两个消息组，A和B，它们按以下顺序发送消息：A1、B1、A2 , B2
即使 A1 尚未删除，也可以提供消息 B1。但是，在删除 A1 之前，将 不会 提供消息 A2。将它们视为 'mini-queues'。这允许处理大量不相关的消息，而不必等待 所有 之前的消息被删除。
参见：Using the Amazon SQS Message Group ID - Amazon Simple Queue Service
Q1: Will both the applications individually receive 100 messages each or will a message that is made available to one consumer won't ever be delivered to the other consumer?
这些都不太准确。
标准队列永远不会故意多次传递一条消息。 可能消息可能偶尔被传递不止一次——但这是例外情况，是 SQS 是一个分布式系统和情况可能会出现，例如，队列将一条消息存储在多个副本中，并且由于内部故障，所有副本都不知道一条消息。
如果一条消息被无意中发送了不止一次，它可能发送给多个消费者或同一个消费者。 SQS 的消费者 "connections" 实际上是无状态的，每次传递消息列表时都会重置，因此 SQS 不知道它向哪个消费者传递了每条消息。
消费者在处理后删除他们的消息，否则他们的可见性超时将过期并且它们会被一次又一次地发送——每次都发送给幸运的消费者。如前所述，SQS 没有消费者身份或状态的概念。 （在大容量应用程序中，单个消费者实际上可能有多个到 SQS 的连接，所有连接都并行接收消息，因为网络往返和 receive/delete 的周期否则会将单个消费者限制为每秒几百条消息. 这些连接是否使用异步 I/O、线程等处理，对 SQS 来说并不重要，它不关心给定连接上有哪个消费者。）
如果要将所有消息发送给所有消费者，则需要从 SNS 到 SQS 的扇出。
Q2: Is the Visibility timeout applicable to both Standard Queue and FIFO Queue?
是的。因为（如上所述）与 SQS 的连接不是持久的、有状态的连接，SQS 使用可见性超时作为消费者丢失消息或非正常失败的指示，因此需要再次使消息可访问。 （死信队列防止这种情况无休止地发生，将消息移动到不同的队列，因为重复的失败表明消费者或 "poison pill" 消息有问题。）
FIFO 队列在此处保留按顺序交付，您可能会争辩说它们恢复为 "at least once" 交付，但我们的想法是这永远不会发生。如果是这样，那么您的可见性超时太短，或者您的消费者崩溃或以其他方式错放消息。
Q3: What are multiple message Groups within a FIFO Queue?
消息组允许 FIFO 队列支持按顺序并行处理组消息，这些消息的排序相对于跨组边界 无关紧要。消息在每个组内按顺序传递。
如果是先进先出队列，如果所有消息都使用相同的组ID发送，那么一次只能有一个消费者在工作。
按顺序传递（简单说明）意味着消息 2 不会传递给任何消费者，直到消息 1 已被消费者接收并删除（完成）。为了交付包括所有处理（不仅仅是初始"delivery"）。或者，如果队列中的 20 条消息具有相同的组 ID，并且两个消费者各请求 10 条消息，则一个消费者获得 10 条消息，而另一个则什么也得不到——但是——因为必须隔离后 10 条消息，直到前 10 条消息被隔离已处理（否则我们不再是 "in order"）。
在20条消息的场景下，如果14条在A组，6条在B组，一个消费者会收到A1-A10，A11-A14会被隔离，直到A1-A10完成，但是第一个消费者忙，另一个消费者可以同时拥有B1-B6。
再次注意，没有消费者亲和力。如果同时删除 A1-A10 和 B1-B6，则 A11-A14 接下来将交付给 one 消费者，但不一定是处理 A1-A10 的消费者。