SQS隊列/可見性超時/消息組

Question

我是AWS的新手。 我想在這里了解SQS。 我也參加了一些培訓，但我仍然無法在討論論壇上得到一些答案。 我在這里重復我的問題。 請注意，我知道下面的一些問題有明顯的答案，因此更多的是一種修辭。 我的困惑源於這樣一個事實，即我對這個主題的理解使我對那些在明顯已知的問題之后出現在我腦海中的后續問題給出了相互矛盾的答案，並且消除了我認為我理解的任何事情的信心。

如果我有一個名為MyQueue的標准隊列並且有100條消息，並且有2個完全獨立的應用程序（作為消費者;請注意它們不是像Kafka中那樣的相同應用程序的消費者組;相反，它們是2個單獨的應用程序）對於這個隊列，消費者可能會收到

（i）無序消息和

（ii）消息的多個副本

我的兩個應用程序都不需要打擾消息的順序。 但是為了這個問題，我們可以說我們有一個完美的交付順序，沒有多個副本，也沒有網絡問題，如果每個消息都在Visibility Timeout窗口內，消費者都會完成處理。

問題1：兩個應用程序是否各自單獨收到100條消息，或者一條消費者可用的消息是否永遠不會傳遞給其他消費者？ 如果后者是真的（沒有網絡問題，無序交付，多次交付），那么：

1. SNS-SQS是否能夠確保多個消費者處理相同的消息？
2. 消費者是否應該在處理后從隊列中刪除消息？ 因此，如果處理器拾取了一條消息，並且在處理發生時它進入可見性超時，即使在可見性超時之前處理完成之后消費者也不會刪除該消息，那么該消息將顯示給其他消費者可能要消耗它？ 如果是這種情況，那么同樣的事情也不適用於FIFO隊列嗎？

其他問題：

Q2：可見性超時是否適用於標准隊列和FIFO隊列？ 如果它也適用於一次傳遞承諾的FIFO隊列，那么，如果在消費者結束處理消息之前出現可見性超時，則它再次出現在隊列中以便再次傳遞，從而返回至少一次處理。 有人可以證實嗎？

問題3： FIFO隊列中的多個消息組是什么？ 他們喜歡隊列的分區嗎？

Answer 1

問：兩個應用程序是否各自單獨收到100條消息？

消費者可以為每個API調用請求最多10條消息。 這些將變為“隱形”， 不會提供給其他消費者。 （嗯，實際上很可能會向多個消費者提供消息。這很少見，但可能會發生。如果這對您的用例不利，那么您應該跟蹤數據庫中的消息以確保它們每個只處理一次。）

問：SNS-SQS是否能夠確保多個消費者處理相同的消息？

想要“多個消費者”消費的單個消息是非常奇怪的。 通常的願望是處理每個消息一次。 如果你確實想要一個由多個消費者處理的消息，那么，是的，你可以將消息發送給SNS，然后SNS可以將它發送到多個隊列。

問：消費者是否應該在處理后從隊列中刪除消息？

是。 Amazon SQS不知道何時處理消息。 消費者必須通過收到消息時提供的ReceiptHandle刪除消息。 如果消息超時且另一個消費者收到消息，則SQS將提供不同的 ReceiptHandle，以便它知道哪個進程請求刪除。

這也適用於FIFO隊列。

問：可見性超時是否適用於標准隊列和FIFO隊列？

是。 如果可見性超時到期，則將消息提供給另一個消費者。 當“標准隊列”中的消息可能被多次提供時，“恰好一次傳送”可以避免上述罕見情況。 但是，如果可見性超時，即使在FIFO隊列中，也會故意在隊列中再次顯示。

問：FIFO隊列中的多個消息組是什么？ 他們喜歡隊列的分區嗎？

消息組是一種對必須按順序傳遞的消息進行分組的方法。

假設有兩個消息組A和B ，它們按以下順序發送消息： A1 ， B1 ， A2 ， B2

即使A1尚未刪除，也可以提供消息B1 。 但是，在刪除A1之前， 不會提供消息A2 。 把它們想象成“迷你隊列”。 這允許處理大量消息是不相關的，而不必等待刪除所有先前的消息。

請參閱： 使用Amazon SQS消息組ID - Amazon Simple Queue Service

Answer 2

問題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的消費者。