問:什麼是 Amazon SQS?

Amazon Simple Queue Service (Amazon SQS) 是可讓您存取訊息佇列的 Web 服務,佇列中存放等待處理的訊息。使用 Amazon SQS,您可以快速建置可在任何電腦上執行的訊息佇列應用程式。

Amazon SQS 提供一個可靠、可高度擴展的託管佇列,以存放在電腦之間傳輸的訊息。使用 Amazon SQS,您可以在各種分散式應用程式元件之間移動資料,既不會遺失訊息,而且每個元件也不需要一直處於可用狀態。

Amazon SQS 與 Amazon Elastic Compute Cloud (Amazon EC2) 和其他 AWS 基礎設施 Web 服務密切合作,可協助您建置具備去耦元件的分散式應用程式。

問:Amazon SQS 可以用來做什麼?

由於 Amazon SQS 可高度擴展,因此您只需依使用量付費。您可以從小規模開始,然後依照業務需求擴展應用程式,且不會影響效能或可靠性。Amazon SQS 協助您專注在建置複雜的以訊息為基礎的強大應用程式,而不必為訊息的存放和管理操心。

以下提供一些想法:

  • 將 Amazon SQS 與其他 AWS 服務整合,讓應用程式更加靈活、更加可靠。
  • 使用 Amazon SQS 建立工作佇列,其中每則訊息是一個任務,需要由一個程序來完成。讓一或多部電腦從訊息佇列讀取任務,然後進行處理。
  • 建置一個微型服務架構,然後使用訊息佇列連接微型服務。
  • 將重大商業事件的通知存放在 Amazon SQS 佇列中。每個事件可以在訊息佇列中有一則對應的訊息,需要注意該事件的應用程式可以讀取和處理該訊息。

問:如何開始使用 Amazon SQS?

完成在分散式應用程式之間傳送訊息 10 分鐘教學,只要幾個步驟就能建立 Amazon SQS 佇列和傳送訊息。

如需詳細資訊,請參閱 Amazon SQS Developer Guide資源中心的範本程式碼

問:Amazon SQS 相較於自主或封裝式訊息佇列系統有哪些好處?

與建置自己的軟體來管理訊息佇列或使用商業或開放原始碼訊息佇列系統相比,Amazon SQS 能帶來多種好處,因為自建軟體的開發和組態需要在前期投入大量時間。

這些替代方案需要持續硬體維護和系統管理資源。由於需要訊息冗餘儲存以確保訊息不會在硬體故障時遺失,這使得這些系統的設定和管理更加複雜。

相反地,Amazon SQS 不需要管理開銷,而且只需要進行一些設定。Amazon SQS 以每天處理數十億則訊息的龐大規模運作。您可以擴展或縮減傳送到 Amazon SQS 的流量,無須進行任何設定。Amazon SQS 還提供極高的訊息耐久性,可讓您和合作夥伴感到更加安心。

問:Amazon SQS 與 Amazon SNS 有何不同?

Amazon Simple Queue Service (SQS) 和 Amazon SNS 都是 AWS 的簡訊服務,但為開發人員提供不同的優點。Amazon SNS 允許應用程式透過「推送」機制向多個訂閱者傳送時效性訊息,並且無須定期檢查或「輪詢」更新。Amazon SQS 是供分散式應用程式使用的訊息佇列服務,它透過輪詢模式交換訊息,可用來分開傳送和接收元件。Amazon SQS 使分散式應用程式元件可以靈活地傳送和接收訊息,無須要求每個元件同時可用。

常見的模式是使用 SNS 將訊息發布至 Amazon SQS 訊息佇列,以非同步方式可靠地將訊息傳送至一或多個系統元件。如需詳細資訊,請參閱什麼是發佈/訂閱簡訊?

問:Amazon SQS 與 Amazon MQ 有何不同?

Amazon MQ、Amazon SQS 和 Amazon SNS 是簡訊服務,適合新創公司到大型企業的各種工作人員使用。如果您使用現有應用程式來傳送簡訊,並想以輕鬆快速的方式將簡訊移到雲端,我們建議您考慮 Amazon MQ。它支援業界標準的 API 和協定,所以您可從任何標準訊息代理程式切換到 Amazon MQ,無須在應用程式重新編寫簡訊程式碼。如果您在雲端建立全新的應用程式,我們建議您考慮 Amazon SQS 和 Amazon SNS。Amazon SQS 和 Amazon SNS 是輕量型的全受管訊息佇列和主題服務,可以近乎無限地擴展,而且提供簡單易用的 API。您可以使用 Amazon SQS 和 SNS 來分離和擴展微型服務、分散式系統及無伺服器應用程式,並且提高可靠性。

問:Amazon SQS 是否提供訊息排序?

是。FIFO (先入先出) 佇列保留訊息傳送和接收的確切順序。如果您使用 FIFO 佇列,則不需要在訊息中放置序列資訊。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 FIFO Queue Logic

標準佇列提供鬆散的 FIFO 功能,以嘗試保留訊息順序。但是,由於標準佇列的設計可以透過高度分散式架構進行大幅度的擴展,因此無法保證接收訊息的順序會與訊息傳送的順序完全相同。

問:Amazon SQS 是否能夠保證交付訊息?

標準佇列提供至少交付一次功能,這代表每個訊息至少會交付一次。

FIFO 佇列提供只處理一次的功能,這代表每個訊息會交付一次,並且會在消費者處理和刪除該訊息之前保持可用狀態。此佇列不會引入重複項目。

 

問:Amazon SQS 與 Amazon Kinesis Streams 有何不同?

Amazon SQS 提供可靠、可高度擴展的託管佇列用以存放訊息,以便在應用程式或微型服務之間移動。它能夠在分散式應用程式元件之間移動資料,並協助您去耦這些元件。Amazon SQS 提供常用的中介軟體建構,像是無效字母佇列和毒藥政策管理。同時還提供一般 Web 服務 API,AWS 開發套件支援的任何程式設計語言都可存取。Amazon SQS 同時支援標準和 FIFO 佇列。

當每個唯一訊息只需要使用一次的時候,以及在如下的案例情況,使用 Amazon SQS:

  • 去耦應用程式的元件:您有一個工作項目佇列,而且希望分別追蹤每個項目的成功完成情況。Amazon SQS 可追蹤確認/失敗結果,因此應用程式無須維護持久性檢查點或游標。設定可見性逾時之後,Amazon SQS 會刪除確認收到的訊息,並重新交付失敗的訊息。
  • 設定個別訊息延遲:您有一個任務佇列,而且需要排程個別工作的延遲。您可以透過 Amazon SQS 將個別訊息設定為最多 15 分鐘的延遲。
  • 動態增加讀取時間的並行數量或輸送量:您有一個工作佇列,而且想要在清除積存之前新增更多讀取器。透過 Amazon Kinesis Streams,您可以擴展到足夠的碎片數量 (但是必須提前佈建足夠的碎片)。Amazon SQS 不需要預先佈建。
  • 以透明方式擴展:由於業務的偶爾負載尖峰或自然成長,您會緩衝請求和負載變更。因為 Amazon SQS 可以個別處理每個緩衝的請求,所以 Amazon SQS 可以利用透明的方式進行擴展來處理負載,您無須提供任何佈建指示。

Amazon Kinesis Streams 可以即時處理大數據串流,而且能夠讀取記錄並將記錄播放到多個 Amazon Kinesis 應用程式。Amazon Kinesis Client Library (KCL) 能夠將指定分區索引鍵的所有記錄交付給相同記錄處理器,讓它更輕鬆地建置從相同 Amazon Kinesis 串流讀取資料的多個應用程式 (例如,執行計數、彙總和篩選)。

當您需要讓多個消費者能夠處理每個記錄,以及在如下的使用案例情況,使用 Amazon Kinesis Streams:

  • 將相關記錄路由到相同的記錄處理器:串流 MapReduce。當指定鍵值的所有記錄都路由到相同記錄處理器時,計數和彙總等動作就會變得較為簡單。
  • 讓多個應用程式同時使用相同的串流:您有一個應用程式在更新即時儀表板,而另一個應用程式則將資料存檔到 Amazon Redshift。您希望這兩個應用程式並行且獨立地使用相同串流的資料。

問:Amazon 在自己的應用程式中是否使用 Amazon SQS?

是。Amazon 開發人員在各種應用程式使用 Amazon SQS,以處理每天大量的訊息。Amazon.com 與 Amazon Web Services 的關鍵商業程序都使用 Amazon SQS。


問:Amazon SQS 的費用是多少?

按實際用量付費,而且沒有最低費用。

Amazon SQS 的費用是依請求個別計算,再加上從 Amazon SQS 傳出資料的數據傳輸費 (除非資料傳輸到相同區域內的 Amazon EC2 執行個體或 AWS Lambda 函數)。如需各佇列類型和區域的詳細定價明細,請參閱 Amazon SQS 定價

問:Amazon SQS 免費方案可用來做些什麼?

Amazon SQS 免費方案每月免費提供 100 萬個請求。

許多小規模應用程式應該能夠完全在這個免費方案限制內操作。不過,可能仍然需要支付數據傳輸費。如需詳細資訊,請參閱 Amazon SQS 定價

免費方案是每月優惠,免費使用量不能跨月累計。

問:我是否需要支付所有 Amazon SQS 請求的費用?

是,您需要支付免費方案以外的任何請求費用。所有 Amazon SQS 請求都要計費,且以同一費率計費。

問:與其他請求相比,Amazon SQS 批次處理操作是否成本更高?

否。批次處理操作 (SendMessageBatch、DeleteMessageBatch 和 ChangeMessageVisibilityBatch) 的所有費用都與其他 Amazon SQS 請求相同。透過將訊息群組為批次,可降低 Amazon SQS 的費用。

問:使用 Amazon SQS 如何計價和收費?

開始使用 Amazon SQS 無須支付初始費用。月底將自動從您的信用卡扣取當月用量的費用。

您可以隨時在 AWS 網站上查看目前計費期間的費用。

  1. 登入您的 AWS 帳戶。
  2. Your Web Services Account 下選取 Account Activity

問:如何追蹤和管理與 Amazon SQS 佇列相關的成本?

您可以使用成本分配標籤,針對資源和成本管理來標記和追蹤佇列。標籤是包含鍵值組的中繼資料標籤。例如,您可以依照成本中心標記佇列,然後根據這些成本中心分類和追蹤成本。

如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Tagging Your Amazon SQS。如需 AWS 資源成本分配標記的詳細資訊,請參閱 AWS Billing and Cost Management User Guide 中的 Using Cost Allocation Tags

問:價格含稅嗎?

除非另有說明,否則我們的價格不包括任何適用的稅金和關稅 (如增值稅和適用的營業稅)。

帳單地址在日本的客戶若使用任何區域的 AWS,則需負擔日本消費稅。如需詳細資訊,請參閱 Amazon Web Services 消費稅常見問答集


問:Amazon SQS 是否可與其他 AWS 服務搭配使用?

是。若要讓應用程式更具彈性和可擴展性,使用 Amazon SQS 時可搭配運算服務 (如 Amazon EC2、Amazon EC2 Container Service (Amazon ECS) 和 AWS Lambda) 和儲存及資料庫服務 (如 Amazon Simple Storage Service (Amazon S3) 和 Amazon DynamoDB) 一起使用。

其中一個常用案例是分散式去耦應用程式,它有多個元件或模組需要互相通訊,但無法同時處理相同的工作量。在此情形下,Amazon SQS 訊息佇列會承載訊息,由 Amazon EC2 執行個體上執行的應用程式進行處理。

Amazon EC2 執行個體可以讀取該訊息佇列、處理任務,然後以訊息的形式將結果發佈到另一個 Amazon SQS 訊息佇列 (例如,交由其他應用程式進一步處理)。由於 Amazon EC2 允許應用程式動態擴展和縮減,應用程式開發人員可根據 Amazon SQS 佇列中的訊息量,使用 Auto Scaling 改變運算執行個體的數量,以確保可及時處理任務。

問:可以提供 Amazon SQS 的範例使用案例嗎?

下面介紹一個影片轉碼網站如何搭配使用 Amazon EC2、Amazon SQS、Amazon S3 和 Amazon DynamoDB:

  1. 最終使用者需要將轉碼的影片提交到網站。
  2. 影片存放到 Amazon S3 中,將一則請求訊息排入傳入 Amazon SQS 佇列,訊息中包含了指向影片和目標影片格式的指標。
  3. 在一組 Amazon EC2 執行個體上執行的轉碼引擎從傳入佇列中讀取請求訊息、使用其中的指標從 Amazon S3 中擷取影片,並將影片轉碼為目標格式。
  4. 轉換後的影片會放回 Amazon S3 中,而另一則回應訊息則會排入另一個傳出 Amazon SQS 佇列,其中包含了指向轉換後影片的指標。
  5. 同時,影片相關的中繼資料 (格式、建立日期和長度等等) 可以在 Amazon DynamoDB 中編製索引,以方便查詢。

在整個工作流程中,一個專用的 Auto Scaling 執行個體可以持續監控傳入佇列。根據傳入佇列中的訊息數量,Auto Scaling 執行個體能夠動態調整轉碼 Amazon EC2 執行個體的數量以滿足網站客戶對回應時間的要求。

問:如何與 Amazon SQS 互動?

您可以使用 AWS 管理主控台存取 Amazon SQS,以協助您輕鬆建立 Amazon SQS 佇列和傳送訊息。

Amazon SQS 還提供 Web 服務 API。而且也已經與 AWS 開發套件整合,可讓您使用自己選擇的程式設計語言。

問:訊息佇列有哪些可用操作?

有關訊息佇列操作的資訊,請參閱 Amazon SQS 產品詳細資訊

問:誰可以在訊息佇列執行操作?

只有 AWS 帳戶擁有者 (或帳戶擁有者已指派權利的 AWS 帳戶) 可在 Amazon SQS 訊息佇列執行操作。

問:Java Message Service (JMS) 是否可與 Amazon SQS 搭配使用?

是。利用 Amazon SQS 的可擴展性、低成本和高可用性,您就無須為執行自己的 JMS 叢集而操心和支付高額的開銷。

Amazon 提供實作 JMS 1.1 規格的 Amazon SQS Java 簡訊庫,並使用 Amazon SQS 做為 JMS 提供者。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Using JMS with Amazon SQS

問:Amazon SQS 如何識別訊息?

所有訊息都有全域唯一的 ID,Amazon SQS 在訊息遞送到訊息佇列時會傳回該 ID。對訊息執行任何進一步動作不需要該 ID,但對於追蹤訊息佇列中的某個特定訊息回條則很有用。

從訊息佇列接收訊息時,回應中包含刪除訊息時必須提供的接收控點。

問:Amazon SQS 如何處理未成功處理的訊息?

在 Amazon SQS 中,您可以使用 API 或主控台來設定無效字母佇列,這是用來接收其他來源佇列訊息的佇列。

如果您將佇列設定為無效字母佇列,它會在無法完成嘗試處理次數上限之後收到訊息。您可以使用無效字母佇列隔離無法處理的訊息,以供日後分析。

如需詳細資訊,請參閱這個頁面上的「是否可在 FIFO 佇列使用無效字母佇列?」,以及 Amazon SQS Developer Guide 中的 Using Amazon SQS Dead Letter Queues

問:什麼是可見性逾時?

可見性逾時是 Amazon SQS 防止其他使用元件接收和處理訊息的一段時間。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Visibility Timeout

問:Amazon SQS 如何允許多個讀取者存取同一個訊息佇列,而不會遺失訊息或重複處理訊息?

每個 Amazon SQS 佇列都具有可設定的可見性逾時。從訊息佇列中讀取訊息時,該訊息會有一段指定的時間不會顯示給其他讀取者。只要訊息的處理時間短於可見性逾時,每則訊息都將會進行處理並予以刪除。

如果處理訊息的元件發生失敗或變成不可用,可見性逾時結束後該訊息將會再次讓讀取該訊息佇列的任何元件看見。這可讓多個元件從相同訊息佇列讀取訊息,而每個原則處理不同的訊息。

問:訊息可見性最長限制是多久?

Amazon SQS 訊息的可見性逾時上限為 12 小時。

問:Amazon SQS 是否支援訊息中繼資料?

是。Amazon SQS 訊息最多可包含 10 個中繼資料屬性。您可以使用訊息屬性將訊息內文與描述該訊息的中繼資料分開。這有助於以更快的速度和更高的效率來處理和存放資訊,因為您的應用程式不需要檢查整個訊息,即可了解所需的處理步驟。

Amazon SQS 訊息屬性採用 name-type-value 三元素格式。支援的類型包括字串、二進位和數字 (包括整數、浮點數和雙精度數)。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Using Amazon SQS Message Attributes

問:如何判斷排隊時間值?

若要判斷排隊時間值,可在接受訊息時請求 SentTimestamp 屬性。將目前時間減去該值即可獲得排隊時間值。

問:Amazon SQS 延遲一般多長?

SendMessage、ReceiveMessage 及 DeleteMessage API 請求的延遲一般為數十或一百多毫秒。

問:匿名存取時,訊息的 SenderId 屬性值為何?

AWS 帳戶 ID 無法使用 (例如,當匿名使用者傳送訊息) 時,Amazon SQS 會提供 IP 地址。

問:什麼是 Amazon SQS 長輪詢?

Amazon SQS 長輪詢是從 Amazon SQS 佇列擷取訊息的方法。即使輪詢的訊息佇列為空,一般短輪詢仍會立即回應,而長輪詢只會在訊息送達訊息佇列或長輪詢逾時的時候才傳回回應。

一旦有訊息,長輪詢可立即從您的 Amazon SQS 佇列擷取該訊息,且價格非常低廉。使用長輪詢可能會降低使用 SQS 的成本,因為可以降低空白接收數。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Amazon SQS Long Polling

問:使用 Amazon SQS 長輪詢是否需要支付其他費用?

否。長輪詢 ReceiveMessage 呼叫的收費方式與短論詢 ReceiveMessage 呼叫的收費方式完全相同。

問:何時使用 Amazon SQS 長輪詢,何時使用 Amazon SQS 短輪詢?

幾乎在所有情況下,使用 Amazon SQS 長輪詢都比使用 Amazon SQS 短輪詢更好。長輪詢請求可以使您的佇列消費者在訊息抵達佇列時立即收到訊息,同時減少傳回空 ReceiveMessageResponse 執行個體的次數。

在大部分的使用案例中,Amazon SQS 長輪詢都可提升效能並降低成本。不過,如果您的應用程式期待從 ReceiveMessage 呼叫收到立即的回應,則可能必須對應用程式進行一些修改,才能利用長輪詢的優勢。

例如,如果您的應用程式使用單一執行緒輪詢多個佇列,從短輪詢切換到長輪詢可能不可行,因為單一執行緒會等待所有空佇列的長輪詢逾時,進而導致延遲處理可能包含訊息的任何佇列。

在這類應用程式中,最好的作法是使用單一執行緒處理一個佇列,進而使應用程式能夠利用 Amazon SQS 長輪詢的優勢。

問:應該在長輪詢逾時設定什麼值?

一般情況下,長輪詢逾時最長應設定為 20 秒。因為較高的長輪詢逾時值會減少傳回空 ReceiveMessageResponse 執行個體的次數,因此盡可能將長輪詢逾時設得越高越好。

如果 20 秒的最長逾時不適用於您的應用程式 (請參閱上一個問題的範例),可以設定較短的長輪詢逾時值,最短為 1 秒。

預設情況下,所有 AWS 開發套件都使用 20 秒的長輪詢。如果您不使用 AWS 開發套件存取 SQS,或者您已經特地將 AWS 開發套件設定為較短逾時,則您可能需要修改 Amazon SQS 用戶端,以允許更長的請求或者使用較短的長輪詢逾時。

問:什麼是適用於 Java 的 AmazonSQSBufferedAsyncClient?

適用於 Java 的 AmazonSQSBufferedAsyncClient 可實作 AmazonSQSAsyncClient 界面,並新增了數個重要功能:

  • 自動批次處理多個 SendMessage、DeleteMessage 或 ChangeMessageVisibility 請求,不需要對應用程式進行任何變更。
  • 將訊息預先擷取到本機緩衝區,能夠讓您的應用程式立即處理來自 Amazon SQS 的訊息,無須等到擷取訊息。

自動批次處理和預先擷取功能搭配使用,可提高輸送量並降低應用程式延遲,同時減少 Amazon SQS 請求的數量以降低成本。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Client-Side Buffering and Request Batching

Amazon SQS 緩衝的非同步用戶端目前不支援 FIFO 佇列。

問:哪裡可以下載適用於 Java 的 AmazonSQSBufferedAsyncClient?

您可以在 適用於 Java 的 AWS 開發套件下載 AmazonSQSBufferedAsyncClient。

問:是否必須重新編寫應用程式才能使用適用於 Java 的 AmazonSQSBufferedAsyncClient?

否。實作適用於 Java 的 AmazonSQSBufferedAsyncClient 時,會將它當成現有 AmazonSQSAsyncClient 的淺顯替代品。

如果您更新應用程式以使用最新的 AWS 開發套件,並變更用戶端以使用適用於 Java 的 AmazonSQSBufferedAsyncClient 來代替 AmazonSQSAsyncClient,您的應用程式將獲得自動批次處理和預先擷取功能所帶來的額外優勢。

問:如何訂閱 Amazon SQS 訊息佇列,以便接收來自 Amazon SNS 主題的通知?

  1. 在 Amazon SQS 主控台中,選取一個 Amazon SQS 標準佇列。
  2. Queue Actions 的下拉式清單中選取 Subscribe Queue to SNS Topic
  3. 在對話方塊中,從 Choose a Topic 下拉式清單中選擇主題,然後按一下 Subscribe

如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Subscribing a Queue to an Amazon SNS Topic

問:如何向多個 Amazon SQS 佇列散發相同的訊息?

  1. 使用 Amazon SNS 建立一個主題。
  2. 建立多個 Amazon SQS 標準佇列並將其訂閱到 Amazon SNS 主題。
  3. 無論訊息何時傳送到 Amazon SNS 主題,都會散發到 Amazon SQS 訊息佇列。

Amazon SNS 會將該訊息傳送到所有訂閱該主題的 Amazon SQS 訊息佇列。

問:Amazon SNS 是否為 Amazon SQS 佇列提供至少交付一次訊息功能?

Amazon SNS 的設計是至少會將每個訊息交付到 Amazon SQS 標準佇列一次。

問:是否能刪除訊息佇列中的所有訊息,但不刪除訊息佇列本身?

是。您可以使用 PurgeQueue 動作刪除 Amazon SQS 訊息佇列中的所有訊息。

當您清除訊息佇列時,所有之前傳送到訊息佇列的訊息都將刪除。由於您的佇列及其屬性都將保留下來,因此不需要重新設定訊息佇列;您可以繼續使用它。

如果只想刪除特定的訊息,可以使用 DeleteMessage 或 DeleteMessageBatch 動作。


問:標準佇列FIFO 佇列有何不同?

標準佇列

Amazon SQS 提供標準做為預設的佇列類型。標準佇列可讓您每秒有近乎無限的交易數。標準佇列可保證訊息至少會交付一次。然而,偶爾 (由於允許高輸送量的高度分散式架構) 可能會有一個以上的訊息副本無法依順序交付。標準佇列會盡力提供最佳的排序功能,以確保訊息通常可按照傳送的順序來交付。

sqs-what-is-sqs-standard-queue-diagram

只要應用程式可以處理抵達超過一次且未照順序排列的訊息,您就可以在許多案例使用標準訊息佇列,例如:

  • 從密集型背景工作去耦即時使用者請求:讓使用者在重新調整大小或編碼時能上傳媒體。
  • 將任務分配到多個工作者節點:處理大量的信用卡驗證請求。
  • 批次處理訊息以供日後處理:排程要新增到資料庫的多個項目。

FIFO 佇列

此佇列類型最重要的功能就是 FIFO (先入先出) 交付,並且只處理一次:嚴格保持訊息傳送和接收的順序,而且訊息只會交付一次,並在消費者處理和刪除該訊息之前保持可用狀態;此佇列不會引入重複項目。FIFO 佇列也允許單一佇列中有多個排序的訊息群組。FIFO 佇列的限制為每個 API 動作每秒 300 個交易數 (TPS),但擁有標準佇列的所有功能。

sqs-what-is-sqs-fifo-queue-diagram



當操作和事件的順序很重要或者不能接受重複項目時,FIFO 佇列的設計可加強應用程式之間的簡訊功能,例如:

  • 確保以正確順序執行使用者輸入的命令。
  • 透過以正確順序傳送價格修改來顯示正確的產品價格。
  • 避免學員在註冊帳戶之前註冊課程。

問:哪些區域提供 FIFO 佇列?

目前在美國西部 (奧勒岡)、美國東部 (俄亥俄)、美國東部 (維吉尼亞北部) 和歐洲 (愛爾蘭) 等區域提供 FIFO 佇列。未來幾個月會在更多區域提供此功能。

問:我會收到幾份訊息副本?

FIFO 佇列的設計永遠不會出現重複的訊息。不過,訊息生產者可能會在某些情況下放入重複項目:例如,如果生產者傳送一則訊息,但沒有收到回應,然後重新傳送相同的訊息。Amazon SQS API 提供重複資料刪除功能,可避免您的訊息生產者傳送重複的訊息。訊息生產者引入的任何重複項目都會在 5 分鐘的重複資料刪除間隔內移除。

對於標準佇列,您可能偶爾會收到重複的訊息副本 (至少交付一次)。如果您使用標準佇列,必須將應用程式設計為等冪 (也就是說,如果它處理相同的訊息超過一次以上,必須不受負面影響)。

問:我之前使用的 Amazon SQS 佇列是否會變更為 FIFO 佇列?

否。Amazon SQS 標準佇列 (現有佇列的全新名稱) 保持不變,而且您仍然可以建立標準佇列。這些佇列會持續提供最高的擴展性和輸送量;但無法保證順序的正確性,且可能收到重複的訊息。

標準佇列適用於許多案例,像是有多個等冪消費者的工作分發。

問:是否可以將現有的標準佇列轉換成 FIFO 佇列?

否。您必須在建立時選擇佇列類型。不過,還是有方法可以轉換成 FIFO 佇列。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Moving From a Standard Queue to a FIFO Queue

問:Amazon SQS FIFO 佇列是否具備回溯相容性?

要利用 FIFO 佇列功能,您必須使用最新的 AWS 開發套件。

FIFO 佇列使用與標準佇列相同的 API 動作,而且接收和刪除訊息以及變更可見性逾時的機制都一樣。不過,傳送訊息時,您必須指定訊息群組 ID。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 FIFO Queue Logic

重要:您無法將現有標準佇列轉換成 FIFO 佇列。若要轉換,您必須為應用程式建立新的 FIFO 佇列,或刪除現有的標準佇列後重新建立為 FIFO 佇列。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Moving from a Standard Queue to a FIFO Queue

問:Amazon SQS FIFO 佇列與哪些 AWS 或外部服務相容?

某些會傳送通知給 Amazon SQS 的 AWS 或外部服務即使允許您將 FIFO 佇列設為目標,仍有可能與 FIFO 佇列不相容。

下列 AWS 服務功能目前與 FIFO 佇列不相容:

有關其他服務與 FIFO 佇列的相容性資訊,請參閱您所使用服務的文件。

問:Amazon SQS FIFO 佇列是否與 Amazon SQS 緩衝非同步用戶端、適用於 Java 的 Amazon SQS Extended Client Library 或 Amazon SQS Java Message Service (JMS) 用戶端相容?

FIFO 佇列目前與 Amazon SQS 緩衝非同步用戶端不相容。

FIFO 佇列與適用於 Java 的 Amazon SQS Extended Client Library 和 Amazon SQS Java Message Service (JMS) 用戶端相容。

問:Amazon SQS FIFO 佇列支援哪些 AWS CloudWatch 指標?

FIFO 佇列支援標準佇列支援的所有指標。對於 FIFO 佇列,所有近似值指標都會傳回正確的計數。例如,支援下列 AWS CloudWatch 指標:

  • ApproximateNumberOfMessagesDelayed – 佇列中延遲且無法立即讀取的訊息數。
  • ApproximateNumberOfMessagesVisible – 可從佇列擷取的訊息數。
  • ApproximateNumberOfMessagesNotVisible – 傳輸中的訊息數 (傳送到用戶端但尚未刪除或可見性時段尚未結束)。

問:什麼是訊息群組?

訊息在 FIFO 佇列內會按照順序組成不同的「服務包」。每個訊息群組 ID 中的所有訊息都以嚴格的順序傳送和接收。不過,擁有不同訊息群組 ID 值的訊息可能不會依照順序傳送和接收。您必須建立訊息群組 ID 和訊息之間的關聯。如果沒有提供訊息群組 ID,動作就會失敗。

如果多個主機 (或相同主機的不同執行緒) 將擁有相同訊息群組 ID 的訊息傳送到 FIFO 佇列,Amazon SQS 會以這些訊息抵達進行處理的順序交付訊息。為了確保 Amazon SQS 維持訊息傳送和接收的順序,請確定多個寄件者以唯一的訊息群組 ID 傳送每個訊息。 

問:Amazon SQS FIFO 佇列是否支援多個生產者?

是。一或多個生產者可以傳送訊息到 FIFO 佇列。系統會依照 Amazon SQS 成功接收訊息的順序存放訊息。

如果多個生產者同時傳送訊息,且未等待 SendMessage 或 SendMessageBatch 動作的成功回應,則可能不會保留生產者間的順序。SendMessage 或 SendMessageBatch 動作的回應包含 FIFO 佇列用來將訊息放到佇列的最終順序序列,所以您的多個平行生產者代碼可判斷佇列中訊息的最後順序。

問:Amazon SQS FIFO 佇列是否支援多個消費者?

Amazon SQS FIFO 佇列的設計不會將來自相同訊息群組的訊息一次傳送到多個消費者。但如果 FIFO 佇列有多個訊息群組,就可以利用平行消費者,允許 Amazon SQS 將不同訊息群組的訊息傳送到不同消費者。

問:是否可在 FIFO 佇列使用無效字母佇列?

是。不過,在 FIFO 佇列必須使用 FIFO 無效字母佇列。(同樣地,在標準佇列只能使用標準無效字母佇列。)

問:Amazon SQS FIFO 佇列的輸送量限制為何?

如果不使用批次處理,FIFO 佇列每秒最多支援 300 則訊息 (每秒 300 次 SendMessage、ReceiveMessage 或 DeleteMessage 操作)。如果使用每個操作 10 則訊息的批次上限,FIFO 佇列每秒最多支援 3,000 則訊息。Amazon SQS 標準佇列擁有無限的輸送量。

問:FIFO 佇列屬性是否有特定的限制?

FIFO 佇列的名稱的結尾必須是 .fifo 尾碼。這個尾碼算在佇列名稱的 80 個字元限制內。若要確認佇列是否是 FIFO,您可檢視佇列名稱是否以尾碼結尾。


問:將資料儲存在 Amazon SQS 的可靠性如何?

Amazon SQS 會將所有訊息佇列和訊息存放在一個高度可用、包含多個冗餘可用區域 (AZ) 的 AWS 區域,這樣單一電腦、網路或 AZ 的故障就不會導致無法存取訊息。如需詳細資訊,請參閱 Amazon Relational Database Service User Guide 中的 Regions and Availability Zones

問:如何保護我訊息佇列中的訊息?

身份驗證機制可確保存放在 Amazon SQS 訊息佇列中的訊息受到保護,不受未經授權的存取。您可以控制誰能傳送訊息到訊息佇列,以及誰可以從訊息佇列接收訊息。如需增加安全性,您可以建置應用程式,將訊息加密後再放入訊息佇列中。

Amazon SQS 本身有以資源為基礎的許可系統,該系統使用的政策編寫語言與 AWS Identity and Access Management (IAM) 政策相同:例如,您可以使用變數,就像在 IAM 政策中一樣。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Amazon SQS Policy Examples

Amazon SQS 支援透過 SSL (HTTPS) 連接 HTTP 和 Transport Layer Security (TLS) 協定。大部分用戶端會自動協調以使用較新版的 TLS,而不用變更任何程式碼或組態。Amazon SQS 在所有區域中都支援版本 1.0、1.1 和 1.2 的 Transport Layer Security (TLS) 協定。

問:為什麼會有單獨的 ReceiveMessage 和 DeleteMessage 操作?

Amazon SQS 傳回訊息給您時,無論您實際上是否收到該訊息,該訊息都保存在訊息佇列中。您要負責刪除該訊息,而刪除請求可確認您已處理了該訊息。

如果您不刪除訊息,Amazon SQS 將在收到另一個接收請求時再次遞送該訊息。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Visibility Timeout

問:是否會再次收到刪除的訊息?

否。FIFO 佇列不會有重複的訊息。

至於標準佇列,在極少數情形下,您可能會再次收到之前刪除的訊息。這樣的情形很少發生,由於分散式 Amazon SQS 系統中的某部伺服器在執行刪除時無法使用,DeleteMessage 操作未能刪除訊息的所有副本。該訊息副本可能會被再次遞送。如果您使用標準佇列,請將應用程式設計成等幕 (也就是說,再次收到已刪除的訊息時不會出現錯誤或不一致)。

問:如果對之前已刪除的訊息發出 DeleteMessage 請求,會發生什麼情況?

對之前已刪除的訊息發出 DeleteMessage 請求時,Amazon SQS 會傳回一個 success 回應。


問:適用於 Amazon SQS 的伺服器端加密 (SSE) 有哪些好處?

伺服器端加密 (SSE) 可讓您在加密佇列中傳輸敏感資料。SSE 使用 AWS Key Management Service (AWS KMS) 中管理的金鑰保護 Amazon SQS 佇列中的訊息內容。SSE 在 Amazon SQS 一收到訊息時立刻加密。訊息以加密格式存放,而 Amazon SQS 只會在訊息傳送給授權的取用者時才會解密訊息。

AWS KMS 結合安全、高可用性的硬體和軟體,提供針對雲端調整的金鑰管理系統。

以下是使用 AWS KMS 的好處:

  • 您可以自己建立和管理客戶主金鑰 (CMK)
  • 您也可以為 Amazon SQS 使用 AWS 受管 CMK,每個帳戶和區域都有唯一的 CMK。 
  • AWS KMS 安全標準可協助您符合加密相關的合規要求。

如需詳細資訊,請參閱下列資源:

問:哪些區域可使用包含 SSE 的佇列?

美國東部 (維吉尼亞北部及俄亥俄) 和美國西部 (奧勒岡) 等區域可使用適用於 Amazon SQS 的 SSE。未來幾個月會在更多區域提供此功能。

問:如何為新的或現有 Amazon SQS 佇列啟用 SSE?

若要使用 Amazon SQS API 為新的或現有佇列啟用 SSE,請透過設定 CreateQueue 或 SetQueueAttributes 動作的 KmsMasterKeyId 屬性來指定客戶主金鑰 (CMK) ID:AWS 受管 CMK 或自訂 CMK 的別名、別名 ARN、金鑰 ID 或金鑰 ARN。

如需詳細指示,請參閱 Amazon SQS Developer Guide 中的 Creating an Amazon SQS Queue with Server-Side EncryptionConfiguring Server-Side Encryption (SSE) for an Existing Amazon SQS Queue

問:哪些 Amazon SQS 佇列類型可以使用 SSE?

標準佇列和 FIFO 佇列都支援 SSE。

問:我需要哪些許可才能在 Amazon SQS 使用 SSE?

您必須先設定 AWS KMS 金鑰政策允許加密佇列及加密和解密訊息,才可以使用 SSE。

若要為佇列啟用 SSE,您可以為 Amazon SQS 使用 AWS 受管客戶主金鑰 (CMK) 或自訂 CMK。如需詳細資訊,請參閱 AWS KMS Developer Guide 中的 Customer Master Keys

若要將訊息傳送至加密佇列,生產者必須擁有 CMK 的 kms:GenerateDataKey 和 kms:Decrypt 許可。

若要從加密佇列收到訊息,取用者必須擁有用來加密指定佇列中訊息的任何 CMK 的 kms:Decrypt 許可。如果佇列是無效字母佇列,取用者也必須有用來加密來源佇列中訊息的任何 CMK 的 kms:Decrypt 許可。

如需詳細資訊,請參閱 What Permissions Do I Need to Use SSE? (在 Amazon SQS Developer Guide 中)。

問:使用 SSE 搭配 Amazon SQS 是否需要付費?

無須支付額外的 Amazon SQS 費用。不過,從 Amazon SQS 呼叫 AWS KMS 需要付費。如需詳細資訊,請參閱 AWS Key Management Service 定價

使用 AWS KMS 的費用取決於為佇列設定的資料金鑰重複使用期間。如需詳細資訊,請參閱 How Do I Estimate My AWS KMS Usage Costs? (在 Amazon SQS Developer Guide 中)。

問:Amazon SQS 的 SSE 會加密哪些元件及其加密方式?

SSE 會加密 Amazon SQS 佇列中訊息的內文。

SSE 不會加密下列元件:

  • 佇列中繼資料 (佇列名稱和屬性)
  • 訊息中繼資料 (訊息 ID、時間戳記和屬性)
  • 每佇列指標

Amazon SQS 會根據 Amazon SQS 的 AWS 受管客戶主金鑰 (CMK) 或自訂 CMK 產生資料金鑰,提供可設定時間期間 (從 1 分鐘到 24 小時) 的信封加密和訊息解密。

問:Amazon SQS 的 SSE 使用哪種演算法來加密訊息?

SSE 使用 AES-GCM 256 演算法

問:SSE 是否會影響 Amazon SQS 的運作?

加密訊息是讓未授權或匿名使用者無法看到訊息的內容。加密訊息並不會影響 Amazon SQS 的正常運作:

  • 訊息只會在佇列加密啟用之後傳送時才會進行加密。Amazon SQS 不會加密積存的訊息。
  • 即使佇列停用加密,任何已加密的訊息仍維持加密狀態。

問:加密的 Amazon SQS 佇列如何與非加密佇列和無效字母佇列共存?

將訊息移至無效字母佇列不會影響其加密:

  • 如果將訊息從加密來源佇列移至未加密無效字母佇列,訊息仍維持加密狀態。
  • 如果將訊息從未加密來源佇列移至加密無效字母佇列,訊息仍維持未加密狀態。

問:SSE 是否會限制 Amazon SQS 可建立的每秒交易數 (TPS) 或佇列數?

SSE 不會限制 Amazon SQS 的輸送量 (TPS)。您可以建立的 SSE 佇列數受到下列限制:

  • 資料金鑰重複使用期間 (1 分鐘到 24 小時)。
  • AWS KMS 每帳戶限制 (預設為 100 個 TPS)。
  • 存取佇列的 IAM 使用者數或帳戶數。
  • 大量積存 (更大量的積存需要更多 AWS KMS 呼叫)。

例如,我們假設下列限制:

  • 您將資料金鑰重複使用期間設定為 5 分鐘 (300 秒)。
  • 您的 KMS 帳戶預設 AWS KMS TPS 限制為 100 個 TPS。
  • 您使用的 Amazon SQS 佇列沒有積存,而且有 1 位 IAM 使用者對所有佇列執行 SendMessage 或 ReceiveMessage 動作。

在這個案例中,可以計算使用 SSE 在理論上的最大 Amazon SQS 佇列數:

300 秒 × 100 個 TPS/1 位 IAM 使用者 = 30,000 個佇列

問:如何預估我的 AWS KMS 用量費用?

若要預估 AWS 帳單的費用並更清楚地了解帳單明細,您需要知道 Amazon SQS 使用 CMK 的頻率。

注意:雖然下列公式可讓您清楚理解預估的費用,但是由於 Amazon SQS 的分散式性質,實際費用可能更高。

若要計算每佇列的 API 請求數 (R),請使用下列公式:

R = B/D * (2 * P + C)

B 是計費期間 (以秒為單位)

D資料金鑰重複使用期間 (以秒為單位)

P 是傳送到 Amazon SQS 佇列的生產主體數。

C 是從 Amazon SQS 佇列接收的取用主體數。

重要:一般而言,生產主體會產生取用主體兩倍的費用。如需詳細資訊,請參閱 How Does the Data Key Reuse Period Work? (在 Amazon SQS Developer Guide 中)。

如果生產者和取用者有不同的 IAM 使用者,費用會增加。

如需計算範例,請參閱 How Do I Estimate My Customer Master Key (CMK) Usage Costs? (在 Amazon SQS Developer Guide 中)。如需確實的定價資訊,請參閱 AWS KMS 服務定價


問:Amazon SQS PCI DSS 是否經過認證?

是。Amazon SQS 已經過 PCI DSS 第 1 級認證。如需詳細資訊,請參閱 PCI 合規

問:Amazon SQS 是否是 HIPAA 合格服務?

是,AWS 已經擴展其 HIPAA 合規計劃,將 Amazon SQS 納入 HIPAA 合格服務。如果您擁有與 AWS 共同履行的商業夥伴協議 (BAA),可以使用 Amazon SQS 建立 HIPAA 合規應用程式、存放傳輸中的訊息和傳輸訊息 (包括內含受保護醫療資訊 (PHI) 的訊息)。

如果已經擁有與 AWS 共同履行的 BAA,則可立即開始使用 Amazon SQS。如果沒有 BAA 或對在 HIPAA 合規應用程式使用 AWS 有任何問題,請聯絡我們以取得詳細資訊。

注意:如果您不想透過 Amazon SQS 傳輸 PHI (或者您的訊息大於 256 KB),可改為使用適用於 Java 的 Amazon SQS Extended Client Library 透過 Amazon S3 傳送 Amazon SQS 訊息承載 (Amazon S3 是 HIPAA 合格服務,不包含使用 Amazon S3 Transfer Acceleration)。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Using the Amazon SQS Extended Client Library for Java


問:訊息在 Amazon SQS 訊息佇列中可保留多久?

較長的訊息保留期可提供更大的靈活性,允許在訊息產生和消耗之間有更長的間隔。

Amazon SQS 訊息保留期值的設定範圍為 1 分鐘到 14 天。預設值是 4 天。達到訊息保留期限之後,就會自動刪除您的訊息。

問:如何設定 Amazon SQS 以支援更長的訊息保留期?

要設定訊息保留期,請使用主控台或使用 Distributiveness 方法設定 MessageRetentionPeriod 屬性。使用此屬性指定 Amazon SQS 保留訊息的秒數。

您可以使用 MessageRetentionPeriod 屬性,將訊息保留期設定為 60 秒 (1 分鐘) 到最長 1,209,600 秒 (14 天)。如需使用此訊息屬性的詳細資訊,請參閱 Amazon SQS API Reference

問:如何設定 Amazon SQS 的訊息大小上限?

要設定最大訊息大小,請使用主控台或 SetQueueAttributes 方法設定 MaximumMessageSize 屬性。此屬性指定 Amazon SQS 訊息可以包含的大小限制 (單位為位元組)。將此限制值設定在 1,024 位元組 (1 KB) 到 262,144 位元組 (256 KB) 之間。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Using Amazon SQS Message Attributes

若要傳送大於 256 KB 的訊息,可以使用 Amazon SQS Extended Client Library for Java。此程式庫可讓您傳送 Amazon SQS 訊息,其中包含 Amazon S3 訊息承載的參考,大小可達 2 GB。 

問:訊息中可以包含哪種類型的資料?

Amazon SQS 訊息可包含最多 256 KB 的文字資料,包括 XML、JSON 和無格式文字。接受以下 Unicode 字元:

#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #x10FFFF]

如需詳細資訊,請參閱 XML 1.0 規格

問:Amazon SQS 訊息佇列的大小可以是多少?

一個 Amazon SQS 訊息佇列可以包含無限則訊息。不過,標準佇列的傳輸中訊息數量限制為 120,000,而 FIFO 佇列則是 20,000。訊息會在從佇列接收後但尚未從佇列刪除時,由使用的元件傳遞。

問:可以建立多少個訊息佇列?

您可以建立任意數量的訊息佇列。

問:Amazon SQS 訊息佇列名稱是否有大小限制?

佇列名稱限制為 80 個字元。

問:Amazon SQS 訊息佇列的名稱是否有限制?

您可以使用英數字元、連字號 (-) 和底線 (_)。

問:可以重複使用訊息佇列名稱嗎?

訊息佇列名稱在 AWS 帳戶和區域中必須是唯一的。您可以刪除訊息佇列之後,重新使用該名稱。


問:如何共用訊息佇列?

您可以建立存取政策陳述式 (和指定要授予的許可) 與共用訊息佇列的關聯。Amazon SQS 提供建立和管理存取政策陳述式的 API:

  • AddPermission
  • RemovePermission
  • SetQueueAttributes
  • GetQueueAttributes

如需詳細資訊,請參閱 Amazon SQS API Reference

問:共用佇列存取由誰支付費用?

訊息佇列擁有者負責支付共用訊息佇列存取的費用。

問:如何識別要共用訊息佇列的其他 AWS 使用者?

Amazon SQS API 使用 AWS 帳號識別 AWS 使用者。

問:要與 AWS 使用者共用訊息佇列時,需要將哪些資料提供給 AWS 使用者?

要與 AWS 使用者共用訊息佇列時,請提供要共用之訊息佇列的完整 URL。CreateQueue 和 ListQueues 操作會在回應中傳回此 URL。

問:Amazon SQS 是否支援匿名存取?

是。您可以設定允許匿名使用者存取訊息佇列的存取政策。

問:何時應使用 Permissions API?

Permissions API 對開發人員提供一個共用訊息佇列存取權的界面。不過,這個 API 不允許有條件存取和更為進階的使用案例。

問:何時應該使用 SetQueueAttributes 操作搭配 JSON 物件?

SetQueueAttributes 操作支援完整的存取原則語言。例如,您可以使用政策語言,依 IP 地址和時間對訊息佇列的存取進行限制。如需詳細資訊,請參閱 Amazon SQS Developer Guide 中的 Amazon SQS Policy Examples


問:哪些區域提供 Amazon SQS?

對於提供服務的區域,請參閱 AWS 全球基礎設施區域表
注意:目前只在美國西部 (奧勒岡)、美國東部 (俄亥俄)、美國東部 (維吉尼亞北部) 和歐洲 (愛爾蘭) 等區域提供 FIFO 佇列。未來幾個月會在更多區域提供此功能。

問:是否可與不同區域的佇列共用訊息?

否。每個區域中的 Amazon SQS 訊息佇列都是各自獨立的。

問:不同區域之間是否有定價差別?

Amazon SQS 的定價在所有區域都一致,僅中國 (北京) 例外。如需詳細資訊,請參閱 Amazon SQS 定價

問:各個區域之間的定價結構為何?

您可以在單一區域內的 Amazon SQS 與 Amazon EC2 或 AWS Lambda 之間免費傳輸資料。

在不同區域的 Amazon SQS 與 Amazon EC2 或 AWS Lambda 之間傳輸資料時,會向您收取標準的資料傳輸費。如需詳細資訊,請參閱 Amazon SQS 定價