RabbitMQ消息隊列（一）-RabbitMQ的優劣勢及產生背景

本篇並無直接講到技術，例如沒有先寫個Helloword。我想在選擇瞭解或者學習一門技術以前先要明白爲何要如今這個技術而不是其餘的，以避免到最後發現本身學錯了。同時若是已經肯定就是他，最好先要了解下技術產生的背景等因素，以便對技術有更深入全面的瞭解（那句話怎麼講的「你不瞭解過去的我，又怎麼理解如今的我」）。

爲何使用RabbitMQ

---

爲何我開始選擇學習RabbitMQ：

1. 安裝部署簡單，上手門檻低，功能豐富，符合AMQP標準；
2. 企業級消息隊列，通過大量實踐考驗的高可靠；
3. 集羣易擴展，能夠輕鬆的增減集羣節點；
4. 有強大的WEB管理頁面。

企業爲何將RabbitMQ做爲消息隊列系統：

在我學習RabbitMQ的初期我在網上查到一些這方面的資料，我認爲比較好的是下面這封http://www.doc88.com/p-5826232080382.html 一方面是他對於RabbitMQ的評價自己，更重要的是對於技術選型評價的兩個維度：十萬米高空看技術和顯微鏡看技術。

十萬米高空看RabbitMQ：

1. 有商業化的運營，不會輕易死掉；
2. 遵循AMQP協議，不會被綁架；
3. 強大的社區支持，爲技術進步提供動力；
4. 大量成功的應用案例，例如阿里、網易等互聯網巨頭都有使用。

顯微鏡看RabbitMQ：

1. Erlang開發，AMQP的最佳搭檔，在支持持久化的消息隊列中性能算很優秀的；
2. 支持消息持久化、支持消息確認機制、靈活的任務分發機制等，支持功能很是豐富；
3. 可靠性高；
4. 集羣擴展很容易，而且能夠經過增長節點實現成倍的性能提高；
5. WEB管理和監控，有些技術癌更喜歡命令行界面，但WEB管理爲後期運維提供很大的便利。
   RabbitMQ劣勢：
   在kafka和zero面前性能被虐成渣，（持久化消息和ACK確認的狀況下生產和消費消息單機大約在1-2萬左右）

結論：若是你但願使用一個可靠性高、功能強大、易於管理的消息隊列系統那麼就選擇RabbitMQ吧，若是你想用一個性能高，但偶爾丟點數據不是很在意可使用kafka或者zeroMQ。

RabbitMQ產生的背景

---

一、消息隊列系統最在能夠追溯到上個世紀（是否是感受好久遠，實際上是1983年，那時候我還沒用出生）。1983年最先的消息隊列軟件Teknekron誕生，當時緊用於一些金融交易等系統。

二、上世紀九十年代，誕生了多家消息隊列系統，例如IBM MQ、微軟的MSMQ、TIBCO MQ等消息隊列在企業中的應用也越發普遍。顯然這些商用的消息隊列系統若是企業要使用須要付出高昂的成本，而且各個消息隊列之間使用不一樣的API不一樣的協議。

三、2004年，AMQP（Advanced Message Queuing Protocol,高級消息隊列協議）開始開發。經過這一標準能夠和任意AMQP供應商提供的MQ服務進行交互。

四、2006年，光陰荏苒時光如梭，一轉眼就說到了重點。咱們的主角使用Erlang語言實現的AMQP開源版本，RabbitMQ誕生了，同年AMQP協議首次發佈。

爲何叫RabbitMQ？
不少人估計和我同樣也有這個疑問，我在《RabbitMQ實戰》這本書中找到了答案：兔子行動很是迅速並且繁殖起來也很是瘋狂，因此就把Rabbit用做這個分佈式軟件的命名（就是真麼簡單）。

 

轉自：https://blog.csdn.net/super_rd/article/details/70229714