消息隊列簡介及應用場景相關：
消息隊列（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：置為多大是一個經驗值來的。一般來說“生產者”突增大量消息，而“消費者”短時間無法處理完，這樣消息就會停留在消息隊列中，而停留的消息數是有限制的，超出此限制的消息將無法寫入。但如果不限制則隊列新進來的請求需要等未處理的請求處理完。