本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon SQS 能見度超
當消費者從 Amazon SQS 佇列收到訊息時,訊息會保留在佇列中,但其他消費者會暫時看不見訊息。此暫時隱形是由可見性逾時所控制,這種機制可防止其他消費者在處理相同的訊息時處理相同的訊息。Amazon SQS 不會自動刪除訊息,而是在成功處理訊息後,取用者必須使用DeleteMessage
動作明確刪除訊息。
設定可見性逾時
只要將訊息傳回給消費者,Amazon 中的可見度逾時就會SQS開始。在此期間,消費者預期會處理並刪除訊息。不過,如果取用者無法在可見性逾時到期前刪除訊息,則訊息會再次顯示在佇列中,而且可由其他用戶擷取。
每個 Amazon SQS 佇列的預設可見性逾時為 30 秒,但您可以根據應用程式的需求調整此設定。通常最好將可見性逾時設定為符合應用程式處理和刪除訊息所需的最長時間。您也可以為個別訊息設定特定的可見性逾時,而不必變更佇列的整體逾時設定。
航班訊息配額
在 Amazon 中SQS,傳送中訊息是消費者從佇列接收但尚未刪除的訊息。對於標準佇列,傳輸中訊息的數量有限制,視佇列流量和訊息積壓而定,最多可達約 120,000 個。
-
短輪詢 — 如果在使用短輪詢時達到此限制,Amazon SQS 將傳回
OverLimit
錯誤訊息,指出在刪除某些傳送中訊息之前無法接收其他訊息。 -
長輪詢 — 如果您使用長輪詢,Amazon SQS 不會在達到執行中訊息限制時傳回錯誤。相反,直到飛行中消息的數量降到限制以下,它將不會返回任何新消息。
若要有效管理傳送中訊息並避免達到此配額:
-
提示刪除 — 確保成功處理郵件後立即刪除,以減少傳輸中計數。
-
監控方式 CloudWatch — 使用 Amazon CloudWatch 監控傳送中訊息的數量,並設定警示以在接近限制時提醒您。
-
分配負載 — 如果您正在處理大量郵件,請考慮增加佇列數目,以分配負載並防止瓶頸。
-
要求增加配額 — 如有必要,請將支援要求提交至 AWS 以增加應用程式的傳送中訊息配額。
了解標準和FIFO佇列中的可見性逾時
Amazon 中的可見性逾時可SQS管理標準和FIFO佇列中的訊息處理,以防止重複處理和維護訊息順序。
-
標準佇列 — 在標準佇列中,可見性逾時有助於防止多個取用者同時處理相同的訊息。但是,由於 Amazon 的交付模式至少有一次SQS,因此無法絕對保證訊息在可見性逾時期間不會傳送超過一次。
-
FIFOqueue — 在 FIFO (先進先出) 佇列中,可見性逾時可確保以正確順序處理具有相同訊息群組 ID 的訊息。如果取用者在可見性逾時到期前未刪除訊息,則除非郵件再次顯示或刪除,否則不會傳遞具有相同群組識別碼的新郵件。對FIFO佇列而言,請務必謹慎管理可見性逾時,以維護訊息順序和處理完整性。
如果消費者無法處理消息會發生什麼情況
如果消費者因應用程式錯誤、當機或連線問題等問題而無法處理訊息,而且未在可見性逾時到期之前刪除訊息,訊息就會自動再次顯示在佇列中。一旦可見,該消息可以由相同或不同的消費者檢索到另一個處理嘗試。此程序可確保即使初始處理失敗,也不會遺失訊息。
不過,請務必注意,如果可見性逾時設定得太高,則會延遲未處理訊息的重新出現,進而降低重試次數的速度。根據預期的處理時間設定適當的可見性逾時對於及時訊息處理至關重要。
變更和終止可見性逾時
根據您的需求,SQS使用ChangeMessageVisibility
動作來管理訊息處理,變更或終止 Amazon 中的可見性逾時。
-
變更逾時 — 如果初始可見性逾時不足,您可以使用
ChangeMessageVisibility
動作對其進行調整。此動作可讓您根據處理需求縮短或延長逾時。 -
終止逾時 — 如果您決定不處理已接收的訊息,您可以透過
ChangeMessageVisibility
動作將設定VisibilityTimeout
為 0 秒來終止其可見性逾時。這會立即使訊息可供其他消費者處理。
最佳實務
使用下列最佳實務管理 Amazon 中的能見度逾時SQS,包括設定、調整和延長逾時,以及使用無效信件佇列 () 處理未處理的訊息。DLQs
-
設定和調整逾時。首先設定可見性逾時,以符合應用程式通常需要處理和刪除訊息的最長時間。如果您不確定確切的處理時間,請從較短的逾時 (例如 2 分鐘) 開始,並視需要延長逾時。您可以實作活動訊號機制,以定期延長可見性逾時,確保訊息在處理完成之前保持不可見狀態。這樣可將重新處理未處理訊息的延遲降到最低,並防止過早的可見性。
-
延長逾時並處理 12 小時限制。如果您的處理時間有所不同或可能超過最初設定的逾時,請在處理訊息時使用
ChangeMessageVisibility
動作來延長可見性逾時。請記住,可見性逾時的最大限制是從第一次收到訊息開始算起 12 小時。延長逾時不會重設此 12 小時限制。如果您的處理需要的時間超過此限制,請考慮使用 AWS Step Functions 或將任務分解為更小的步驟。實際上,如果接收訊息和更新逾時之間存在延遲,則立即將可見性逾時設定為完整 12 小時限制可能會失敗。為了避免這種情況,請使用稍低的值,例如 43,195 秒。
-
處理未處理的郵件若要管理多次處理嘗試失敗的郵件,請設定無效字母佇列 ()。DLQ這可確保在數次重試之後無法處理的訊息會分別擷取以供進一步分析或處理,防止它們在主佇列中重複循環。