使用消息隊列（MQ）的 10 個理由！

過去幾年中，我們一直在使用、建構和宣傳消息隊列，我們認為它們是很令人敬畏的，這也不是什麼秘密。

我們相信對任何架構或應用來說，消息隊列都是一個至關重要的元件，下面是十個理由:

1、解耦

在項目啟動之初來預測将來項目會碰到什麼需求，是極其困難的。消息隊列在處理過程中間插入了一個隐含的、基于資料的接口層，兩邊的處理過程都要實作這一接口。這允許你獨立的擴充或修改兩邊的處理過程，隻要確定它們遵守同樣的接口限制。

2、備援

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

3、擴充性

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

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

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

5、可恢複性

當體系的一部分元件失效，不會影響到整個系統。消息隊列降低了程序間的耦合度，是以即使一個處理消息的程序挂掉，加入隊列中的消息仍然可以在系統恢複後被處理。而這種允許重試或者延後處理請求的能力通常是造就一個略感不便的使用者和一個沮喪透頂的使用者之間的差別。

6、送達保證

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

7、排序保證

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

8、緩沖

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

9、了解資料流

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

10、異步通信

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

我們相信上述十個原因，使得消息隊列成為在程序或應用之間進行通信的最好形式。

原文出自：

http://blog.iron.io/\

譯文：

https://www.oschina.net/translate/top-10-uses-for-message-queue\

翻譯 : lwei, Garfielt, YuanyuanL, wang7x

近期熱文推薦：

1.600+ 道 Java面試題及答案整理(2021最新版)

2.終于靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！

3.阿裡 Mock 工具正式開源，幹掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式釋出，全新颠覆性版本！

5.《Java開發手冊（嵩山版）》最新釋出，速速下載下傳！

覺得不錯，别忘了随手點贊+轉發哦！