原文地址：

http://www.cnblogs.com/reck/articles/3680368.html

訊息佇列（Message Queue）：把訊息按照產生的次序加入佇列，而由另外的處理程式/模組將其從佇列中取出，並加以處理；從而形成了一個基本的訊息佇列。

使用訊息佇列可以很好地將任務以非同步的方式進行處理，或者進行資料傳送和儲存等。

例如，當你頻繁地向資料庫中插入資料、頻繁地向搜尋引擎提交資料，就可採取訊息佇列來非同步插入。另外，還可以將較慢/較複雜的處理邏輯、有併發數量限制的處理邏輯，通過訊息佇列放在後臺處理。

常規的使用場景：簡訊服務、電子郵件服務、圖片處理服務、好友動態推送服務等。

SY： 1：從MQ自身來說，出佇列是按照入佇列的先後順序的－－保證時序性是MQ的一個基本要求。 2：如果異常前資料已經到達MQ，或者尚未從MQ中取出，那麼資料將持續保持有效，異常恢復後可以繼續正常使用。如果異常時資料尚未到達MQ，或者已經從MQ中取出，則該條資料會有丟失的可能（具體情況看各自的客戶端的異常處理機制是否完善）。 3：是的。當任務從MQ中取出後，其執行的正確性、完整性、安全性由取出者保證。 4：任何需要做持久化的產品，最終瓶頸都逃不過磁碟io的限制。 我們能做的是，根據木桶原理，確保系統中不出線其它比磁碟io更短的短板。如果確實需要高效能的同時提供持久化和安全性的保障，那麼可以考慮使用ssd硬碟－－實測表明效能提升相當明顯。至於純記憶體的MQ，我們不排除後續版本中增加的可能性。但是混合使用純記憶體和持久化的話，會使使用者無法確保當前到底用的是純記憶體模式還是持久化模式－－這樣，在使用者看來，這樣的MQ既無法時刻保證安全性，也無法時刻提供高效能，所以這樣的MQ是不可信賴的（不可信賴的產品，在稍微重要的場合下，基本上就等於是不可用的）。 8、訊息佇列只用過beanstalkd, 不知道和beanstalkd想比，有什麼差異？能否做多像beanstalkd那樣啟動多個daemon客戶端掛在並行等待處理訊息？有沒有例項可以展示下比如傳送郵件，推送動態等的應用？ SY:你提到的beanstalkd據我的瞭解他是記憶體式的，資料不會持久化的。我那麼回答也是表明其儲存上的差異。對beanstalkd瞭解不深其他方面暫時做不了評價/對比。UCMQ是會將寫入訊息持久化的，例項重啟或異常退出資料都不會丟失，即便是伺服器宕機也只是丟失部分未持久化的資料。同時持久化間隔可配置。 9、您好，在實際開發過程中，我並沒有遇到需要用訊息佇列的需求，對於訊息佇列我也只是停留在概念上， 我想問：訊息佇列的典型應用場景？對於高併發的請求使用訊息佇列是否能保證及時性。訊息佇列設計那哪些基本技術？ SY：訊息佇列是非同步的所以及時性不能保證，至於使用到的技術可以閱讀我寫的部落格（http://tech.uc.cn/?p=1344）或閱讀相關程式碼（https://github.com/ucweb/ucmq）。 10、訊息佇列還沒怎麼接觸，想問下，有什麼應用場景會用到訊息佇列呢？訊息佇列可以解決那些問題咧？？ SY：訊息佇列有自己的一定的特性：非同步/順序讀寫/高效能/協議簡單。所以一般會用於解決大量的伺服器端非同步請求，同時可以實現服務端的負載均衡和業務的容災。 11、訊息佇列產品有很多， 有的提供socket監聽， 不支http協議訪問， 有的支援http協議訪問， 這2者有什麼區別嗎？ 我是否可以理解訊息現在很多訊息佇列都是一個nosql呢？ 訊息佇列和nosql 最顯著區別是什麼？ SY：訊息佇列與NOSQL的不同還是挺顯著的：首先，應用場景不同：nosql是高效的弱關係型資料儲存，訊息佇列是一次性消費的順序訊息元件。其次，資料保持的差異：nosql的資料是持久或定時持久的，訊息佇列的資料隨取出而失效，即一次消費。使用什麼協議都行，用http考慮的是簡單/易接入。 12、訊息佇列和用資料庫做儲存，然後取資料庫內容做處理有什麼區別嗎？ 舉個例子，傳送郵件，我可以先把郵件內容存到是資料庫，然後以掃描資料庫依次傳送。第二點，訊息佇列是多執行緒的嗎？ SY：非同步訊息機制保證正確傳送，不保證及時傳送，簡訊就是這樣 。  1.用資料庫慢。2.多程序或多執行緒讀取資料庫時需要新增標記，否則會造成資料重複，使用訊息佇列不會出現此問題。 13、訊息佇列的長度設定為多大合適？一般是預分配還是動態分配的？ SY：置為多大是一個經驗值來的。一般來說“生產者”突增大量訊息，而“消費者”短時間無法處理完，這樣訊息就會停留在訊息佇列中，而停留的訊息數是有限制的，超出此限制的訊息將無法寫入。但如果不限制則佇列新進來的請求需要等未處理的請求處理完。