一、應用場景及優點
在項目設計、開發過程中，當我們遇到以下幾種情況都可以使用消息隊列：
- 對於一些無需即時返回且耗時的操作；
- 並發要求很高，數據處理很耗時，但是又無需及時返回信息的操作；
- 數據轉移類的操作，比如客戶端和內網都要進行數據傳輸和交換, 現有架構中, 客戶端不能直接訪問內網, 那么客戶端只能: 先把數據保存到外網服務器, 然后內網服務器再拉回來處理. 這種方式可以保證數據都能被處理, 但實效性不夠.通常, 外網服務器只起到一個暫時保存數據的作用, 保存客戶端報上來的數據, 然后等待內網來拉走,把客戶端看做producer, 內網看做consumer, 這正是消息隊列的用武之地。
以上幾個應用場景僅僅是我的一家之言，可以根據具體業務需求，靈活運用，消息隊列更多的是一種解決問題的思路，見仁見智！
消息隊列通過消息的生產/訂閱，把消息寫入消息隊列，通過消費者訂閱提取出來，對數據進行異步處理，而這種異步處理的方式大大的節省了服務器的請求響應時間，從而提高了系統的吞吐量。
另外消息隊列還有兩個優點，平台無關性，分布式部署；這個也是我個人比較看重的地方.
二、目前消息隊列的主流產品
MSMQ：
這是微軟的產品里唯一被認為有價值的東西。對我的客戶來說，如果MSMQ能證明可以應對這種任務，他們將選擇使用它。關鍵是這個東西並不復雜，除了接收和發送，沒有別的；它有一些硬性限制，比如最大消息體積是4MB。然而，通過和一些像MassTransit 或 NServiceBus這樣的軟件的連接，它完全可以解決這些問題。
ActiveMQ：
Java世界的中堅力量。它有很長的歷史，而且被廣泛的使用。它還是跨平台的，給那些非微軟平台的產品提供了一個天然的集成接入點。然而，它只有跑過了MSMQ才有可能被考慮。
RabbitMQ：
我聽說了很多關於這個用Erlang寫成的消息中間件的優秀的特性。它支持開放的高級消息隊列協議 (AMQP，Advanced Message Queuing Protocol)，從根本上避免了生產廠商的封閉，使用任何語言的各種客戶都可以從中受益。這種協議提供了相當復雜的消息傳輸模式，所以基本上不需要MassTransit 或 NServiceBus 的配合。它還具有“企業級”的適應性和穩定性。這些東西對客戶來說十分的有吸引力。
我個人也比較偏好使用RabbitMQ，在商業環境中也有使用經驗，能夠承擔商業級應用。
ZeroMQ：
我在研究AMQP時從發現了這個產品。開發這個產品的公司是AMQP集團的一部分，並且還有一個叫做OpenAMQ的產品。然而，他們卻戲劇性的從AMQP分離的出去，並抱怨說這這個產品迷失了方向、變的越來越復雜。你可以到這里閱讀Dear John的關於此事的文章。ZeroMQ具有一個獨特的非中間件的模式，也就是說，跟其它幾個接受測試的產品不同，你不需要安裝和運行一個消息服務器，或中間件。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應用程序之間發送消息了。
三、AMQP
高級消息隊列協議（AMQP）是一個異步消息傳遞所使用的應用層協議規范。作為線路層協議，而不是API（例如JMS），AMQP客戶端能夠無視消息的來源任意發送和接受信息。現在，已經有相當一部分不同平台的服務器和客戶端可以投入使用。
AMQP的原始用途只是為金融界提供一個可以彼此協作的消息協議，而現在的目標則是為通用消息隊列架構提供通用構建工具。因此，面向消息的中間件（MOM）系統，例如發布/訂閱隊列，沒有作為基本元素實現。反而通過發送簡化的AMQ實體，用戶被賦予了構建例如這些實體的能力。這些實體也是規范的一部分，形成了在線路層協議頂端的一個層級：AMQP模型。這個模型統一了消息模式，諸如之前提到的發布/訂閱，隊列，事務以及流數據，並且添加了額外的特性，例如更易於擴展，基於內容的路由。
四、RabbitMQ
本文中的AMQP服務器是使用Erlang編寫的RabbitMQ。它實現了AMQP規范0-8版的內容，並且將在近期實現0-9-1版的內容。
在開始之前再交代一些東西：異步消息是一個非常普通並且廣泛使用的技術，從例如Skype或者XMPP/Jabber這樣各種各樣的即時消息協議到古老的email。
但是，這些服務都有如下特征：
- 它們會在傳輸消息的時候或多或少加入一些隨意的內容（例如一封email可能會包含一個文本和關於辦公室笑話的PPT）和一些比較正式的路由信息（例如email地址）。
- 它們都是異步的，也就是說它們將生產者和消費者區分開來，因此可能將消息加入隊列（例如某人發給你一條消息，但是你不在線或者你的郵箱會收到一封email）。
- 生產者和消費者是具有不同知識的不同角色。我不需要知道你的IMAP用戶名和密碼就能夠給你發送email。事實上，我甚至不需要知道你的email地址是否是一個馬甲或者“真實”地址。這個特性意味着生產者不能控制什么內容被閱讀或者訂閱了 - 就像我的email客戶端會舍棄掉大多數主動發送給我的醫葯廣告。
AMQP是一個抽象的協議（也就是說它不負責處理具體的數據），這個事實並不會將事情變得更復雜。反而，Internet使得消息無處不在。人們通常使用它們和異步消息簡單靈活地解決很多問題。而且構建AMQ中的異步消息架構模型最困難的地方在於上手的時候，一旦這些困難被克服，那么構建過程將變得簡單。
安裝:
需要說明的是，RabbitMQ支持目前主流的所有操作系統，這一點也是吸引我的地方。
- Erlang/OTP包，下載地址是 http://erlang.org/download.html，安裝說明在 http://www.erlang.org/doc/installation_guide/part_frame.html 。
- RabbitMQ，下載地址是 http://www.rabbitmq.com/download.html，安裝說明在 http://www.rabbitmq.com/install.html。
- Python，simplejson 下載地址： http://www.python.org/getit/，http://pypi.python.org/pypi/simplejson#downloads 。
詳細的安裝步驟可以參考：
- http://blog.csdn.net/historyasamirror/article/details/6827870
- http://www.rabbitmq.com/admin-guide.html
RabbitMQ的文檔比較全面，網上資料比較豐富，學習成本相對已經比較低了。
現在你需要做的就是啟動RabbitMQ服務器。
今天到此為止吧，改天再寫關於RabbitMQ的運行機制，后續會出來具體的使用方法，以及我對RabbitMQ的簡單實用封裝。
參考資料：
AMQP和RabbitMQ入門 http://www.infoq.com/cn/articles/AMQP-RabbitMQ