本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon SQS 可見性逾時
當您收到來自 Amazon SQS 佇列的訊息時，它會保留在佇列中，但其他取用者暫時無法看見。此可見性是由可見性逾時所控制，這可確保其他取用者在您處理訊息時無法處理相同的訊息。Amazon SQS 提供兩種在處理後刪除訊息的選項：
+ **手動刪除** – 您可以使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)動作明確刪除訊息。
+ **自動刪除** – 在特定 AWS SDKs中支援，訊息會在成功處理時自動刪除，簡化工作流程。
![\[顯示可見性逾時期間如何處理請求的時間線圖\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-visibility-timeout-diagram.png)
## 可見性逾時使用案例
**管理長時間執行的任務** – 使用可見性逾時來處理需要延長處理時間的任務。為需要延長處理時間的訊息設定適當的可見性逾時。這可確保其他消費者在處理訊息時不會挑選相同的訊息，防止重複的工作並維持系統效率。
**實作重試機制** – 針對無法在初始逾時內完成的任務，以程式設計方式延伸可見性逾時。如果任務無法在初始可見性逾時內完成，您可以透過程式設計方式延長逾時。這可讓您的系統重試處理訊息，而不會讓其他消費者看到訊息，進而改善容錯能力和可靠性。結合**無效字母佇列 (DLQs)** 來管理持久性故障。
**協調分散式系統** – 使用 SQS 可見性逾時來協調分散式系統的任務。設定可見性逾時，以符合不同元件的預期處理時間。這有助於維持一致性，並防止複雜、分散式架構中的競爭條件。
**最佳化資源使用率** – 調整 SQS 可見性逾時，以最佳化應用程式中的資源使用率。透過設定適當的逾時，您可以確保有效處理訊息，而不會不必要的綁定資源。這可提高整體系統效能和成本效益。
## 設定和調整可見性逾時
一旦傳送訊息給您，可見性逾時就會開始。在此期間，您需要處理和刪除訊息。如果您在逾時過期之前未將其刪除，訊息會再次顯示在佇列中，並且可由其他取用者擷取。佇列的預設可見性逾時為 30 秒，但您可以進行調整以符合應用程式處理和刪除訊息所需的時間。您也可以為個別訊息設定特定的可見性逾時，而無需變更佇列的整體設定。視需要使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html)動作，以程式設計方式延長或縮短逾時。
## 傳輸中訊息和配額
在 Amazon SQS 中，傳輸中訊息是消費者已收到但尚未刪除的訊息。對於標準佇列，根據佇列流量和訊息待處理項目，大約有 120，000 個傳輸中訊息的限制。如果您達到此限制，Amazon SQS 會傳回`OverLimit`錯誤，表示在刪除某些傳輸中的訊息之前，無法接收其他訊息。對於 FIFO 佇列，限制取決於作用中的訊息群組。
+ **使用短輪詢時** – 如果在使用短輪詢時達到此限制，Amazon SQS 將傳回`OverLimit`錯誤，表示在刪除某些傳輸中的訊息之前，無法接收其他訊息。
+ **使用長輪詢 –** 如果您使用長輪詢，Amazon SQS 不會在達到傳輸中訊息限制時傳回錯誤。相反地，在傳輸中的訊息數量低於限制之前，不會傳回任何新訊息。
若要有效管理傳輸中的訊息：
1. **刪除提示** – 在處理後刪除訊息 （手動或自動），以減少傳輸中計數。
1. **使用 CloudWatch 監控** - 設定高傳輸中計數的警示，以防止達到限制。
1. **分配負載** – 如果您正在處理大量訊息，請使用額外的佇列或消費者來平衡負載並避免瓶頸。
1. **請求提高配額** – 如果需要更高的限制，請向 [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html) 提交請求。
## 了解標準和 FIFO 佇列中的可見性逾時
在標準和 FIFO First-In-First-Out佇列中，可見性逾時有助於防止多個消費者同時處理相同的訊息。不過，由於 Amazon SQS at-least-once交付模式，因此無法保證在可見性逾時期間不會多次交付訊息。
+ **標準佇列** – 標準佇列中的可見性逾時可防止多個取用者同時處理相同的訊息。不過，由於at-least-once交付模型，Amazon SQS 不保證在可見性逾時期間內不會交付訊息超過一次。
+ **FIFO 佇列** – 對於 FIFO 佇列，具有相同訊息群組 ID 的訊息會以嚴格順序處理。當訊息群組 ID 為進行中的訊息時，該群組中的後續訊息將無法使用，直到刪除進行中訊息或可見性逾時過期為止。不過，這不會無限期地「鎖定」群組 – 每個訊息都會依序處理，而且只有在刪除或再次顯示每個訊息時，該群組中的下一個訊息才會供消費者使用。此方法可確保群組內的排序處理，而不會不必要地鎖定群組來傳遞訊息。
## 處理失敗
如果您未在可見性逾時到期之前處理和刪除訊息，因為應用程式錯誤、當機或連線問題，訊息會再次顯示在佇列中。然後，相同或不同的取用者可以擷取它，以進行另一個處理嘗試。這可確保即使初始處理失敗，訊息也不會遺失。不過，設定過高的可見性逾時可能會延遲未處理訊息的重新出現，從而可能減慢重試速度。請務必根據預期的處理時間來設定適當的可見性逾時，以便及時處理訊息。
## 變更和終止可見性逾時
您可以使用 `ChangeMessageVisibility`動作來變更或終止可見性逾時：
+ **變更逾時** – 使用 動態調整可見性逾時[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html)。這可讓您延長或縮短逾時持續時間，以符合處理需求。
+ **終止逾時** – 如果您決定不處理收到的訊息，請透過 `ChangeMessageVisibility`動作將 `VisibilityTimeout` 設定為 0 秒來終止其可見性逾時。這會立即讓訊息可供其他消費者處理。
## 最佳實務
使用下列最佳實務來管理 Amazon SQS 中的可見性逾時，包括設定、調整和延長逾時，以及使用無效字母佇列 (DLQs) 處理未處理的訊息。
+ **設定和調整逾時。**首先，設定可見性逾時以符合應用程式通常需要處理和刪除訊息的時間上限。如果您不確定確切的處理時間，請從較短的逾時開始 （例如 2 分鐘），並視需要延長。實作活動訊號機制以定期延長可見性逾時，確保訊息在處理完成之前不會顯示。這可將重新處理未處理訊息的延遲降至最低，並防止過早可見。
+ **延長逾時並處理 12-Hour的限制。**如果您的處理時間不同或可能超過最初設定的逾時，請使用 `ChangeMessageVisibility`動作在處理訊息時延長可見性逾時。請記住，可見性逾時的上限為從第一次收到訊息起 12 小時。延長逾時不會重設此 12 小時的限制。如果您的處理需要的時間超過此限制，請考慮使用或將任務 AWS Step Functions 分成較小的步驟。
+ **處理未處理的訊息。**若要管理多次處理嘗試失敗的訊息，請設定無效字母佇列 (DLQ)。這可確保個別擷取多次重試後無法處理的訊息，以供進一步分析或處理，防止它們在主佇列中重複傳播。