在專案啟動之初來**將來專案會碰到什麼需求，是極其困難的。訊息佇列在處理過程中間插入了乙個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面。這允許你獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。
有時在處理資料的時候處理過程會失敗。除非資料被持久化，否則將永遠丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險。在被許多訊息佇列所採用的"插入-獲取-刪除"正規化中，在把乙個訊息從佇列中刪除之前，需要你的處理過程明確的指出該訊息已經被處理完畢，確保你的資料被安全的儲存直到你使用完畢。
因為訊息佇列解耦了你的處理過程，所以增大訊息入隊和處理的頻率是很容易的；只要另外增加處理過程即可。不需要改變**、不需要調節引數。擴充套件就像調大電力按鈕一樣簡單。
當體系的一部分元件失效，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使乙個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。而這種允許重試或者延後處理請求的能力通常是造就乙個略感不便的使用者和乙個沮喪透頂的使用者之間的區別。
訊息佇列提供的冗餘機制保證了訊息能被實際的處理，只要乙個程序讀取了該佇列即可。在此基礎上，ironmq提供了乙個"只送達一次"保證。無論有多少程序在從佇列中領取資料，每乙個訊息只能被處理一次。這之所以成為可能，是因為獲取乙個訊息只是"預定"了這個訊息，暫時把它移出了佇列。除非客戶端明確的表示已經處理完了這個訊息，否則這個訊息會被放回佇列中去，在一段可配置的時間之後可再次被處理。
在許多情況下，資料處理的順序都很重要。訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。ironmo保證訊息漿糊通過fifo（先進先出）的順序來處理，因此訊息在佇列中的位置就是從佇列中檢索他們的位置。
在任何重要的系統中，都會有需要不同的處理時間的元素。例如,載入一張比應用過濾器花費更少的時間。訊息佇列通過乙個緩衝層來幫助任務最高效率的執行--寫入佇列的處理會盡可能的快速，而不受從佇列讀的預備處理的約束。該緩衝有助於控制和優化資料流經過系統的速度。
在乙個分布式系統裡，要得到乙個關於使用者操作會用多長時間及其原因的總體印象，是個巨大的挑戰。訊息系列通過訊息被處理的頻率，來方便的輔助確定那些表現不佳的處理過程或領域，這些地方的資料流都不夠優化。
很多時候，你不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許你把乙個訊息放入佇列，但並不立即處理它。你想向佇列中放入多少訊息就放多少，然後在你樂意的時候再去處理它們。
相信上述十個原因，使得訊息佇列成為在程序或應用之間進行通訊的最好形式。
訊息佇列的使用
剛開始看的時候，由兩個疑問，我自己的答案是這樣的 1.訊息佇列在系統中的最大個數，關於這個問題，書上有明確的答案 書上有個 列明了linux free bsd，mac os x solaris中的典型值。當然也可以通過一些手段來修改。sysctl就可以修改。2.在多個執行緒 或程序 同時對乙個訊息佇...
如何使用訊息佇列的事務訊息
發訊息 過程，往往是為通知另外乙個系統更新資料，mq的 事務 主要解決訊息生產者和訊息消費者的資料一致性問題。先把商品加到購物車 然後幾件商品一起下單 最後支付 完成購物流程，就可以愉快地等待收貨 該過程中有個需用mq。訂單系統建立訂單後，發訊息給購物車模組，將已下單商品從購物車刪除。從購物車刪除已...
RabbitMQ訊息佇列的使用
我們知道rabbitmq的exchange常用交換器型別分為fanout direct topic headers 4種型別，這裡我們將對fanout direct topic 3種型別以實際 的形式進行講解，至於關於交換器對各型別的具體講解，請參照文章開始給出的鏈結進行了解，這裡就不再贅述，我們新...