本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon SQS 訊息處理和計時
<a name="best-practices-message-processing"></a>

本主題提供在 Amazon SQS 中最佳化訊息處理速度和效率的完整指引，包括及時處理訊息的策略、選擇最佳輪詢模式，以及設定長輪詢以提高效能。

****主題****
+ [在 Amazon SQS 中及時處理訊息](best-practices-processing-messages-timely-manner.md)
+ [在 Amazon SQS 中設定長輪詢](best-practices-setting-up-long-polling.md)
+ [在 Amazon SQS 中使用適當的輪詢模式](best-practices-using-appropriate-polling-mode.md)

# 在 Amazon SQS 中及時處理訊息
<a name="best-practices-processing-messages-timely-manner"></a>

可見性逾時設定取決於您的應用程式需要花最久時間處理和刪除訊息。例如，如果您的應用程式需要 10 秒的時間來處理訊息，而您將可見性逾時設定為 15 分鐘，那麼如果先前的處理嘗試失敗，您必須等候相當長的時間才能再次嘗試處理訊息。或者，如果您的應用程式需要 10 秒的時間來處理訊息，但您將可見性逾時設定為只有 2 秒，那麼當原始消費者仍在處理訊息時，另一個消費者就會收到重複的訊息。

為了確保有足夠的時間來處理訊息，請使用以下其中一種策略：
+ 如果您知道 (或可以合理預估) 處理訊息需要多長的時間，請將訊息的*可見性逾時*延長到處理和刪除訊息所需的最長時間。如需詳細資訊，請參閱[設定可見性逾時](sqs-visibility-timeout.md#configuring-visibility-timeout)。
+ 如果您不知道處理一則訊息需要多久，請為您的消費者程序建立*活動訊號*：指定初始可見性逾時 (例如 2 分鐘)—接著只要您的消費者仍在處理訊息—每隔 1 分鐘就將可見性逾時延長 2 分鐘。
**重要**  
最大可見性逾時是從 Amazon SQS 收到 `ReceiveMessage` 請求的時間起算 12 小時。延長可見性逾時不會重設 12 小時的最大值。  
此外，您可能無法將個別訊息的逾時設定為完整 12 小時 (亦即 43,200 秒)，因為 `ReceiveMessage` 要求會啟動計時器。例如，如果您收到一則訊息，並透過傳送 `VisibilityTimeout` 等於 43,200 秒的 `ChangeMessageVisibility` 呼叫來設定 12 小時的最大值，則它可能會失敗。不過，除非透過 `ReceiveMessage` 要求訊息和更新可見性逾時之間有很大的延遲，否則使用值 43,195 秒就可以運作。如果您的消費者需要超過 12 小時，請考慮使用 Step Functions。

# 在 Amazon SQS 中設定長輪詢
<a name="best-practices-setting-up-long-polling"></a>

當 `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)` API 動作的等待時間大於 0 時，*長輪詢*就會生效。最長輪詢等待時間上限為 20 秒。長輪詢可透過減少空回應數量 （當請求沒有可用的訊息時`ReceiveMessage`) 和誤報空回應 （當訊息可用但未包含在回應中時），協助降低使用 Amazon SQS 的成本。如需詳細資訊，請參閱[Amazon SQS 短輪詢和長輪詢](sqs-short-and-long-polling.md)。

為確保最佳訊息處理，請使用下列策略：
+ 在大多數情況下，您可以設定 `ReceiveMessage` 等待時間為 20 秒。如果 20 秒對於您的應用程式來說太長，可以設定較短的 `ReceiveMessage` 等待時間 (最低 1 秒)。如果您不使用 AWS 開發套件存取 Amazon SQS，或者如果您將 AWS 開發套件設定為等待時間較短，則可能需要修改 Amazon SQS 用戶端，以允許更長的請求或使用更短的等待時間進行長輪詢。
+ 如果您對多個佇列實作長輪詢，請為每個佇列使用一個執行緒，而非所有佇列使用單一執行緒。為每個佇列各使用一個執行緒可讓您的應用程式在訊息可供使用時，分別處理每個佇列中的訊息，而將單一執行緒用於輪詢多個佇列則可能導致您的應用程式無法處理其他佇列中的可用訊息，因為它必須等候沒有任何可用訊息的佇列 (最長 20 秒)。

**重要**  
若要避免 HTTP 錯誤，請確定 `ReceiveMessage` 請求的 HTTP 回應逾時比 `WaitTimeSeconds` 參數長。如需詳細資訊，請參閱 [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)。

# 在 Amazon SQS 中使用適當的輪詢模式
<a name="best-practices-using-appropriate-polling-mode"></a>
+ 長輪詢可讓您在訊息一旦從 Amazon SQS 佇列提供使用時，立即使用訊息。
  + 若要降低使用 Amazon SQS 的成本並降低空佇列的空白接收數 (回應未傳回訊息的 `ReceiveMessage` 動作)，請啟用長輪詢。如需詳細資訊，請參閱 [Amazon SQS 長輪詢](sqs-short-and-long-polling.md)。
  + 若要在輪詢具有多個接收訊息的多個執行緒時提高效率，請降低執行緒數量。
  + 在大部分情況下，長輪詢都優於短輪詢。
+ 即使受輪詢的 Amazon SQS 佇列空白，短輪詢仍會立即傳回回應。
  + 若要滿足期望立即回應 `ReceiveMessage` 請求的應用程式要求，請使用短輪詢。
  + 短輪詢的計費與長輪詢相同。