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

# Amazon SQS 佇列類型
<a name="sqs-queue-types"></a>

Amazon SQS 支援兩種佇列類型：[**標準佇列**](standard-queues.md)和 [**FIFO**](sqs-fifo-queues.md) 佇列。使用下表來判斷哪個佇列最符合您的需求。


| 標準佇列 | FIFO 佇列 | 
| --- | --- | 
|  **無限制輸送量** – 標準佇列支援每個動作 ([https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)、 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)或 ) 每秒非常高、幾乎無限制的 API 呼叫數量[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)。這種高輸送量使它們非常適合需要快速處理大量訊息的使用案例，例如即時資料串流或大規模應用程式。雖然標準佇列會隨需求自動擴展，但監控使用模式以確保最佳效能至關重要，尤其是工作負載較高的區域。 **At-least-once傳遞** – at-least-once傳遞，這表示每則訊息至少傳遞一次，但在某些情況下，由於重試或網路延遲，訊息可能會傳遞多次。您應該設計應用程式以使用等冪性操作來處理潛在的重複訊息，以確保多次處理相同的訊息不會影響系統的狀態。 **最努力排序** – 提供最努力的排序，這表示當 Amazon SQS 嘗試按照訊息傳送的順序傳遞訊息時，不保證這一點。在某些情況下，訊息可能無法按順序送達，尤其是在高輸送量或故障復原的情況下。對於訊息處理順序至關重要的應用程式，您應該處理應用程式中的重新排序邏輯，或使用 FIFO 佇列進行嚴格排序保證。 **耐用性和備援** – 標準佇列可跨多個 AWS 可用區域儲存每則訊息的多個副本，以確保高耐用性。這可確保即使發生基礎設施故障，訊息也不會遺失。 **可見性逾時** – Amazon SQS 可讓您設定可見性逾時，以控制訊息在收到訊息後隱藏的時間長度，確保其他消費者不會處理訊息，直到完全處理或逾時過期為止。  | **高輸送量** – 當您使用[批次處理](sqs-batch-api-actions.md)時，每個 API 方法 ([https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)、 或 ) 的 FIFO 佇列每秒最多處理 3[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessageBatch.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessageBatch.html)，000 則訊息[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessageBatch.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessageBatch.html)。此輸送量依賴每秒 300 個 API 呼叫，每個 API 呼叫處理批次 10 個 messages.By 以啟用高輸送量模式，您可以在訊息群組內輕鬆排序，擴展至每秒 30，000 個交易 (TPS)。如果沒有批次處理，FIFO 佇列每個 API 方法 (`SendMessage`、 `ReceiveMessage`或 ) 每秒最多支援 300 個 API 呼叫`DeleteMessage`。如果您需要更多輸送量，您可以透過 [AWS 支援中心](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-sqs)請求提高配額。若要啟用高輸送量模式，請參閱 [在 Amazon SQS 中啟用 FIFO 佇列的高輸送量](enable-high-throughput-fifo.md)。 **精確處理一次** – FIFO 佇列會傳送每則訊息一次，並保持可用狀態，直到您處理和刪除訊息為止。透過使用 [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)或內容型重複資料刪除等功能，您可以防止重複的訊息，即使因網路問題或逾時而重試也一樣。 **First-in-first-out交付** – FIFO 佇列可確保您依訊息群組內傳送的順序接收訊息。透過將訊息分散到多個群組，您可以平行處理訊息，同時保持每個群組中的順序。  | 
|  ![\[標準佇列訊息傳遞。\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-what-is-sqs-standard-queue-diagram.png)  |  ![\[FIFO 佇列訊息傳遞。\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-what-is-sqs-fifo-queue-diagram.png)  | 
| 當輸送量至關重要時，使用標準佇列在應用程式之間傳送資料，例如：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html) |  當事件順序很重要時，使用 FIFO 佇列在應用程式之間傳送資料，例如： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html)  | 

# 在 Amazon SQS 中實作請求回應系統
<a name="implementing-request-response-systems"></a>

實作請求回應或遠端程序呼叫 (RPC) 系統時，請記住下列最佳實務：
+ 在**啟動時建立回覆佇列** – 不是為每個訊息建立回覆佇列，而是在啟動時為每個生產者建立回覆佇列。使用相互關聯 ID 訊息屬性，有效率地將回應映射至請求。
+ **避免在生產者之間共用回覆佇列** – 確保每個生產者都有自己的回覆佇列。共用回覆佇列可能會導致生產者接收其他生產者的回應訊息。

如需使用暫時佇列用戶端實作請求-回應模式的相關資訊，請參閱 [請求-回應訊息模式 (虛擬佇列)](sqs-temporary-queues.md#request-reply-messaging-pattern)。