訊息佇列【轉】

標籤：

轉載自：http://www.oschina.net/translate/top-10-uses-for-message-queue

英文原文：Top 10 Uses For A Message Queue

oschina 推薦於 3年前 (共 7 段, 翻譯完成於 08-21)

參與翻譯(4人)：lwei, Garfielt, Holiday_, wang7x

 

 

過去幾年中，我們一直在使用、構建和宣傳訊息佇列，我們認為它們是很令人敬畏的，這也不是什麼秘密。我們相信對任何架構或應用來說，訊息佇列都是一個至關重要的組件，下面是十個理由:

1. 解耦

在項目啟動之初來預測將來項目會碰到什麼需求，是極其困難的。訊息佇列在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面。這允許你獨立的擴充或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

2. 冗餘

有時在處理資料的時候處理過程會失敗。除非資料被持久化，否則將永遠丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。在被許多訊息佇列所採用的"插入-擷取-刪除"範式中，在把一個訊息從隊列中刪除之前，需要你的處理過程明確的指出該訊息已經被處理完畢，確保你的資料被安全的儲存直到你使用完畢。

3. 擴充性

因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的；只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。擴充就像調大電力按鈕一樣簡單。

4. 靈活性 & 峰值處理能力

當你的應用上了Hacker News的首頁，你將發現訪問流量攀升到一個不同尋常的水平。在訪問量劇增的情況下，你的應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵組件頂住增長的訪問壓力，而不是因為超出負荷的請求而完全崩潰。請查看我們關於峰值處理能力的部落格文章瞭解更多此方面的資訊。

5. 可恢複性

當體系的一部分組件失效，不會影響到整個系統。訊息佇列降低了進程間的耦合度，所以即使一個處理訊息的進程掛掉，排入佇列中的訊息仍然可以在系統復原後被處理。而這種允許重試或者延後處理請求的能力通常是造就一個略感不便的使用者和一個沮喪透頂的使用者之間的區別。

6. 送達保證

訊息佇列提供的冗餘機制保證了訊息能被實際的處理，只要一個進程讀取了該隊列即可。在此基礎上，IronMQ提供了一個"只送達一次"保證。無論有多少進程在從隊列中領取資料，每一個訊息只能被處理一次。這之所以成為可能，是因為擷取一個訊息只是"預定"了這個訊息，暫時把它移出了隊列。除非用戶端明確的表示已經處理完了這個訊息，否則這個訊息會被放回隊列中去，在一段可配置的時間之後可再次被處理。

7.排序保證

在許多情況下，資料處理的順序都很重要。訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。IronMO保證訊息漿糊通過FIFO（先進先出）的順序來處理，因此訊息在隊列中的位置就是從隊列中檢索他們的位置。

8.緩衝

在任何重要的系統中，都會有需要不同的處理時間的元素。例如,載入一張圖片比應用過濾器花費更少的時間。訊息佇列通過一個緩衝層來協助任務最高效率的執行--寫入隊列的處理會儘可能的快速，而不受從隊列讀的預備處理的約束。該緩衝有助於控制和最佳化資料流經過系統的速度。

9. 理解資料流

在一個分布式系統裡，要得到一個關於使用者操作會用多長時間及其原因的總體印象，是個巨大的挑戰。訊息系列通過訊息被處理的頻率，來方便的輔助確定那些表現不佳的處理過程或領域，這些地方的資料流都不夠最佳化。

10. 非同步通訊

很多時候，你不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許你把一個訊息放入隊列，但並不立即處理它。你想向隊列中放入多少訊息就放多少，然後在你樂意的時候再去處理它們。

我們相信上述十個原因，使得訊息佇列成為在進程或應用之間進行通訊的最好形式。我們已經花費了一年時間來建立和學習IronMQ，我們的客戶也通過訊息佇列完成了許多不可思議的事情。隊列是建立強大的分布式應用的關鍵，它可以利用雲技術所提供的所有強大能量。

如果現在你想要開始使用一個高效的、可靠的、託管的訊息佇列，下載IronMQ吧。如果你想聯絡我們的工程師，諮詢如何把隊列整合到你的應用中去，他們隨時歡迎你的訪問：get.iron.io/chat。

訊息佇列【轉】