我是AWS的新手。我想在这里了解SQS。我也参加了一些培训，但我仍然无法在讨论论坛上得到一些答案。我在这里重复我的问题。请注意，我知道下面的一些问题有明显的答案，因此更多的是一种修辞。我的困惑源于这样一个事实，即我对这个主题的理解使我对那些在明显已知的问题之后出现在我脑海中的后续问题给出了相互矛盾的答案，并且消除了我认为我理解的任何事情的信心。
如果我有一个名为MyQueue的标准队列，并且有100条消息，并且有2个完全独立的应用程序（作为消费者;请注意它们不是像Kafka中那样的相同应用程序的消费者组;相反，它们是2个独立的应用程序）对于这个队列，消费者可能会收到
（i）无序消息和
（ii）消息的多个副本
我的两个应用程序都不需要打扰消息的顺序。但是为了这个问题，我们可以说我们有一个完美的交付顺序，没有多个副本，也没有网络问题，如果每个消息都在Visibility Timeout窗口内，消费者都会完成处理。
问题1：两个应用程序是否各自单独收到100条消息，或者一条消费者可用的消息是否永远不会传递给其他消费者？如果后者是真的（没有网络问题，无序交付，多次交付），那么：
其他问题：
Q2：可见性超时是否适用于标准队列和FIFO队列？如果它也适用于一次传递承诺的FIFO队列，那么，如果在消费者结束处理消息之前出现可见性超时，则它再次出现在队列中以便再次传递，从而返回至少一次处理。有人可以证实吗？
问题3：FIFO队列中的多个消息组是什么？他们喜欢队列的分区吗？
问：两个应用程序是否各自单独收到100条消息？
消费者可以为每个API调用请求最多10条消息。这些将变为“隐形”，不会提供给其他消费者。 （嗯，实际上很可能会向多个消费者提供消息。这很少见，但可能会发生。如果这对您的用例不利，那么您应该跟踪数据库中的消息以确保它们每个只处理一次。）
问：SNS-SQS是否能够确保多个消费者处理相同的消息？
想要“多个消费者”消费的单个消息是非常奇怪的。通常的愿望是处理每个消息一次。如果你确实想要一个由多个消费者处理的消息，那么，是的，你可以将消息发送给SNS，然后SNS可以将它发送到多个队列。
问：消费者是否应该在处理后从队列中删除消息？
是。 Amazon SQS不知道何时处理消息。消费者必须通过收到消息时提供的ReceiptHandle删除消息。如果消息超时且另一个消费者收到消息，则SQS将提供不同的ReceiptHandle，以便它知道哪个进程请求删除。
这也适用于FIFO队列。
问：可见性超时是否适用于标准队列和FIFO队列？
是。如果可见性超时到期，则将消息提供给另一个消费者。当“标准队列”中的消息可能被多次提供时，“恰好一次传送”可以避免上述罕见情况。但是，如果可见性超时，即使在FIFO队列中，也会故意在队列中再次显示。
问：FIFO队列中的多个消息组是什么？他们喜欢队列的分区吗？
消息组是一种对必须按顺序传递的消息进行分组的方法。
假设有两个消息组，A和B，它们按以下顺序发送消息：A1，B1，A2，B2
即使B1尚未删除，也可以提供消息A1。但是，在删除A2之前，不会提供消息A1。把它们想象成“迷你队列”。这允许处理大量消息是不相关的，而不必等待删除所有先前的消息。
见：Using the Amazon SQS Message Group ID - Amazon Simple Queue Service
问题1：两个应用程序是否各自单独收到100条消息，或者一条消费者可用的消息是否永远不会传递给其他消费者？
这些都不是很准确。
标准队列从不故意多次传递消息。有时可能会多次传递消息 - 但这是例外情况，并且是SQS是分布式系统这一事实的假象，并且可能出现这样的情况：例如，队列在多个副本中存储了消息以及由于内部故障而导致所有副本都不知道消息的事实。
如果消息无意中被多次传递，则可能是多个消费者或同一个消费者。消费者与SQS的“连接”实际上是无状态的，每次传递消息列表时都会重置，因此SQS无法了解每个消息传递给哪个消费者。
消费者在处理后删除他们的消息，否则他们的可见时间超时并且他们一次又一次地被递送 - 每次都是抽奖运气给他们的消费者。如上所述，SQS没有消费者身份或国家的概念。 （在大批量应用中，单个消费者实际上可能有多个与SQS的连接，所有人都并行接收消息，因为网络往返和接收/删除周期将限制单个消费者每秒几百条消息。使用异步I / O，线程等处理这些连接对于SQS并不重要，因为SQS不关心给定连接上的哪个消费者。）
如果您希望将所有消息发送给所有消费者，则需要从SNS扇出到SQS。
Q2：可见性超时是否适用于标准队列和FIFO队列？
是。因为（如上所述）与SQS的连接不是持久的有状态连接，SQS使用可见性超时作为消费者丢失消息或失败失败的指示，因此需要再次访问消息。 （死信队列阻止这种情况无休止地发生，将消息移动到不同的队列，因为重复的故障表明消费者有问题，或者是“毒丸”消息。）
FIFO队列保留了按顺序交付，在这里，您可以争辩说它们会恢复到“至少一次”交付，但我们的想法是永远不会发生这种情况。如果是这样，那么您的可见性超时太短或者您的消费者正在崩溃或以其他方式错误地放置消息。
问题3：FIFO队列中的多个消息组是什么？
消息组允许FIFO队列支持按顺序并行处理组消息，这些消息在组边界上相对于彼此的排序无关紧要。消息按顺序在每个组内传递。
如果是FIFO队列，如果所有消息都使用相同的组ID发送，则一次只能有一个消费者工作。
按顺序传送（简单说明）意味着消息2将不被传送给任何消费者，直到消息1被消费者接收并删除 - 完成。订单交付包括所有处理（不仅仅是初始“交付”）。或者，如果队列中的20个消息具有相同的组ID，并且两个消费者每个请求10个消息，则一个消费者获得10个消息而另一个消费者什么都没有 - 但是 - 因为那些后10个消息必须被隔离，直到前10个消息已经被隔离已处理（否则我们不再“按顺序”）。
在20个消息场景中，如果14个在A组，6个在B组，一个消费者将获得A1-A10，A11-A14将被隔离，直到A1-A10完成，但是当第一个消费者忙，另一个消费者可以同时拥有B1-B6。
再次注意，没有消费者亲和力。如果A1-A10和B1-B6在同一时刻被删除，则A11-A14接下来将交付给一个消费者，但不一定是处理A1-A10的消费者。