RabbitMQ消息隊列（一）-RabbitMQ的優劣勢及產生背景
本篇並沒有直接講到技術，例如沒有先寫個Helloword。我想在選擇瞭解或者學習一門技術之前先要明白爲什麼要現在這個技術而不是其他的，以免到最後發現自己學錯了。同時如果已經確定就是他，最好先要了解下技術產生的背景等因素，以便對技術有更深刻全面的瞭解（那句話怎麼講的“你不瞭解過去的我，又怎麼理解現在的我”）。
爲什麼使用RabbitMQ
爲什麼我開始選擇學習RabbitMQ：
- 安裝部署簡單，上手門檻低，功能豐富，符合AMQP標準；
- 企業級消息隊列，經過大量實踐考驗的高可靠；
- 集羣易擴展，可以輕鬆的增減集羣節點；
- 有強大的WEB管理頁面。
企業爲什麼將RabbitMQ作爲消息隊列系統：
在我學習RabbitMQ的初期我在網上查到一些這方面的資料，我認爲比較好的是下面這封http://www.doc88.com/p-5826232080382.html 一方面是他對於RabbitMQ的評價本身，更重要的是對於技術選型評價的兩個維度：十萬米高空看技術和顯微鏡看技術。
十萬米高空看RabbitMQ：
- 有商業化的運營，不會輕易死掉；
- 遵循AMQP協議，不會被綁架；
- 強大的社區支持，爲技術進步提供動力；
- 大量成功的應用案例，例如阿里、網易等互聯網巨頭都有使用。
顯微鏡看RabbitMQ：
- Erlang開發，AMQP的最佳搭檔，在支持持久化的消息隊列中性能算很優秀的；
- 支持消息持久化、支持消息確認機制、靈活的任務分發機制等，支持功能非常豐富；
- 可靠性高；
- 集羣擴展很容易，並且可以通過增加節點實現成倍的性能提升；
- WEB管理和監控，有些技術癌更喜歡命令行界面，但WEB管理爲後期運維提供很大的便利。
RabbitMQ劣勢：
在kafka和zero面前性能被虐成渣，（持久化消息和ACK確認的情況下生產和消費消息單機大約在1-2萬左右）
結論：如果你希望使用一個可靠性高、功能強大、易於管理的消息隊列系統那麼就選擇RabbitMQ吧，如果你想用一個性能高，但偶爾丟點數據不是很在乎可以使用kafka或者zeroMQ。
RabbitMQ產生的背景
1、消息隊列系統最在可以追溯到上個世紀（是不是感覺很久遠，其實是1983年，那時候我還沒用出生）。1983年最早的消息隊列軟件Teknekron誕生，當時緊用於一些金融交易等系統。
2、上世紀九十年代，誕生了多家消息隊列系統，例如IBM MQ、微軟的MSMQ、TIBCO MQ等消息隊列在企業中的應用也愈加廣泛。顯然這些商用的消息隊列系統如果企業要使用需要付出高昂的成本，並且各個消息隊列之間使用不同的API不同的協議。
3、2004年，AMQP（Advanced Message Queuing Protocol,高級消息隊列協議）開始開發。通過這一標準可以和任意AMQP供應商提供的MQ服務進行交互。
4、2006年，光陰荏苒時光如梭，一轉眼就說到了重點。我們的主角使用Erlang語言實現的AMQP開源版本，RabbitMQ誕生了，同年AMQP協議首次發佈。
爲什麼叫RabbitMQ？
很多人估計和我一樣也有這個疑問，我在《RabbitMQ實戰》這本書中找到了答案：兔子行動非常迅速而且繁殖起來也非常瘋狂，所以就把Rabbit用作這個分佈式軟件的命名（就是真麼簡單）。
轉自：https://blog.csdn.net/super_rd/article/details/70229714