版權聲明：本文為博主原創文章，未經博主同意不得轉載。 https://blog.csdn.net/hongchangfirst/article/details/25877059

SQS即Simple Queue Service, 是一個分布式的消息隊列服務,使用它非常easy,消息隊列服務能夠用來buffer burst, 使整個服務異步處理,不要求組件始終可用.

開發者最初使用 Amazon SQS 時僅僅需用到五個 API：

CreateQueue、SendMessage、ReceiveMessage、ChangeMessageVisibility 和 DeleteMessage。

Amazon SQS 會盡量保持消息順序，可是由于隊列的分布式特性。SQS無法保證發送消息的先后順序。

每一個 Amazon SQS 隊列都具有可配置的可見性超時(Default Visibility Timeout)。在從隊列中讀取消息后的指定時間內。該消息對其它讀取者保持不可見。

僅僅要消息的處理時間短于可見性超時，每條消息都會得以處理并刪除。假設處理消息的組件出現失敗或不可用，可見性超時結束后該消息即對讀取該隊列的不論什么組件可見。

這同意您讓多個組件同一時候從同一隊列中讀取消息，每一個組件負責處理不同的消息。

?

在 Amazon SQS 返回消息后，該消息會保存在隊列中，稱之為In Flight狀態。刪除請求可確認已處理了該消息。

假設不刪除消息，Amazon SQS 將在還有一個接收請求中遞送該消息。

由于分布式 Amazon SQS 系統中的某臺server在運行刪除時不可用。DeleteMessage 操作未能刪除消息的全部副本。該消息副本可能會被再次遞送。所以應該在應用中進行對應的設計，以便在再次收到已刪除的消息時不會出現錯誤或不一致。?

?假設連續 30 天以上時間沒有針對某個隊列簽發下面不論什么請求，SQS有可能刪除該隊列：SendMessage、ReceiveMessage、DeleteMessage、GetQueueAttributes 和 SetQueueAttributes。設計應用程序時應將此考慮在內，這點比較惡心，認為不應該有這種性質。

短輪詢和長輪詢(差別是是否採樣)

假設使用短輪詢，則您從隊列中檢索消息時。Amazon SQS 會對server的一個子集（基于加權隨機分布）進行採樣，而且僅從這些server返回消息。

這意味著。特定接收請求可能不會返回您的全部消息。或者，假設您的隊列中有少量消息（少于 1 000 條），則意味著，特定請求可能不會返回您的不論什么消息，而興許請求則會返回您的不論什么消息。假設您繼續從您的隊列中檢索消息。則 Amazon SQS 會對全部server進行採樣，您會收到您的全部消息。

使用 Amazon SQS 進行長輪詢的一個優點是：在沒有消息可返回以答復發送到 Amazon SQS 隊列的 ReceiveMessage 請求時。能夠降低空響應數量。

在發送響應之前，長輪詢同意 Amazon SQS 產品等到隊列中的消息可用為止。因此，假設連接沒有超時，則對 ReceiveMessage 請求的響應將至少包括一條可用的消息（假設有）。最多可包括 ReceiveMessage 調用中請求的最大消息數。

Receive Message Wait Time就是設置短輪詢還是長輪詢的,0代表短輪詢,最大到20.

Amazon SQS 使用您須要熟悉的下面三個標識符：

隊列 URL
消息 ID
接收句柄

每一個隊列飛行消息(Messages in Flight)的數量限制為 120,000。

消息被隊列接收后會處于飛行狀態。但尚未從隊列中刪除。

假設達到 120,000 的限制，將會收到一條來自 Amazon SQS 的“OverLimit”錯誤消息。

為避免達到限制。應該在處理消息后將其從隊列刪除。

延遲隊列同意將隊列中新消息的傳遞操作推遲特定的秒數(Delivery Delay)。

假設您創建延遲隊列，則發送到該隊列的不論什么消息在延遲期間對使用者都不可見。延遲隊列相似于可見性超時。由于這兩種功能都使得使用者在特定的時間段內無法獲得消息。

延遲隊列和可見性超時之間的差別在于：對于延遲隊列。消息在首次加入到隊列時是隱藏的；而對于可見性超時，消息僅僅有在從隊列取回后才是隱藏的。

默認拒絕和顯式拒絕的差別非常重要。由于默認拒絕能夠被同意覆蓋，可是顯式拒絕就不能。

顯示拒絕是并的關系,默認拒絕是或的關系.

原文:http://blog.csdn.net/hongchangfirst/article/details/25877059

作者:hongchangfirst

hongchangfirst的主頁:http://blog.csdn.net/hongchangfirst