前言
可能你在沒學消息中間件之前都已經聽過很多概念了，JMS，AMQP，ActiveMQ，RabbitMQ，Kafka，RocketMQ，一個消息中間件怎麼能搞出怎麼多概念？亂不亂啊，
別煩，本文從歷史的角度幫你理清這些MQ和協議之間的關係。
什麼是消息中間件？
消息中間件屬於分佈式系統中的一個子系統，關注於數據的發送和接收，利用高效可靠的消息傳遞機制對分佈式系統中的其餘各個子系統經進行集成
消息中間件的使用場景
1.異步處理
非核心流程異步化，提高系統響應性能
原來用戶註冊一下可能得依次寫數據庫，發送郵件和短信後，才能提示用戶註冊成功
現在只要寫數據庫，寫消息隊列後就直接提示用戶註冊成功，發送郵件和短信是異步處理，提高了響應速度
2.應用解耦
系統不是強耦合，消息接受者可以隨意增加，而不需要修改消息發送者的代碼。消息發送者的成功不依賴消息接受者
rpc實現
消息隊列實現
如果庫存系統出了問題，用戶就不能正常下單，這是不合理的。可以通過消息隊列來解耦。
當有新的系統如廣告系統對用戶的訂單也感興趣的時候，只需要從消息隊列中拿消息即可，訂單系統完全不用改變
3.流量削峰
當上下游系統處理能力存在差距的時候，可以用消息隊列進行緩衝
當有秒殺業務時，一下有大量請求湧入時，很可能造成系統癱瘓，此時可以用消息隊列緩衝一下
4.日誌處理
將消息隊列用在日誌處理中，比如Kafka可以用來解決大量日誌傳輸的問題
5.消息通訊
消息隊列一般都內置了高效的通信機制，因此也可以用於單純的消息通訊，比如實現點對點消息隊列或者聊天室等
消息中間件編年史
1.初見曙光
消息中間件其實誕生的很早，在互聯網應用還是一片荒蕪的年代，有個在美國的印度哥們Vivek Ranadive就設想了一種通用軟件總線，採用發佈訂閱的模式，像主板上的總線一樣供其他相應程序接入。他創辦了一家公司Teknekron，實現了世界上第一個消息中間件The Information Bus(TIB)
2.各自為戰
TIB受到了企業的歡迎，Teknekron的業務發展引起了當時最牛氣的IT公司IBM的注意，於是他們也開始研發了自己消息隊列軟件，於是才有了後來的wesphere mq，微軟也陸續加入了戰團。由於商業壁壘，商業MQ供應商想要解決應用互通的問題，而不是去創建標準來實現不同MQ產品間的互通，或者允許應用程序更改MQ平臺
3.劫制天下
為了打破這個壁壘，同時為了能夠讓消息在各個消息隊列平臺間互融互通， JMS (Java Message Service) 應運而生 。JMS 試圖通過提供公共 Java API 的方式，隱藏單獨 MQ 產品供應 商提供的實際接口，從而跨越了壁壘，以及解決了互通問題。從技術上講， Java 應用程序只需 針對 JMS API 編程，選擇合適的 MQ 驅動即可， JMS 會打理好其他部分 。ActiveMQ 就是 JMS 的 一種實現 。不過嘗試使用單獨標準化接口來膠合眾多不同的接口，最終會暴露出問題，使得 應用程序變得更加脆弱 。所以急需一種新的消息通信標準化方案 。
4.一統江湖
4.在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等聯合制定了 AMQP 的公開標準，由此 AMQP 登上了歷史的舞臺 。它是應用層協議的一個開放標準，以解決眾多消息中間件的需求和拓撲結 構問題 。它為面向消息的中間件設計，基於此協議的客戶端與消息中間件可傳遞消息，並不受 產品、開發語言等條件的限制 。
5.合久必分
LinkedIn在實現消息隊列的時候覺得AMQP規範並不適合自己，所以Kafka並不支持AMQP協議。RocketMQ在實現上借鑑了Kakfa的思想，所以也不支持AMQP協議，並且你會發現在Kafka和RocketMQ中都有類似Topic和Consumer Group的概念，而這些概念在AMQP協議中是不存在的
如何選擇消息中間件
- ActiveMQ 的社區算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。
- RabbitMQ 在吞吐量方面雖然稍遜於 Kafka 和 RocketMQ ，但是由於它基於 erlang 開發，所以併發能力很強，性能極其好，延時很低，達到微秒級。但是也因為 RabbitMQ 基於 erlang 開發，所以國內很少有公司有實力做erlang源碼級別的研究和定製。如果業務場景對併發量要求不是太高（十萬級、百萬級），那這四種消息隊列中，RabbitMQ 一定是你的首選。如果是大數據領域的實時計算、日誌採集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範。
- RocketMQ 阿里出品，Java 系開源項目，源代碼我們可以直接閱讀，然後可以定製自己公司的MQ，並且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些。還有就是阿里出臺的技術，你得應對這個技術萬一被拋棄，社區黃掉的風險，如果你們公司有技術實力我覺得用RocketMQ 挺好的
- Kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，而且分佈式可以任意擴展。同時 Kafka 最好是支撐較少的 topic 數量即可，保證其超高吞吐量。Kafka 唯一的一點劣勢是有可能消息重複消費，那麼對數據準確性會造成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響可以忽略。Kafka天然適合大數據實時計算以及日誌收集。
AMQP協議詳解
前面說到消息中間件有2種協議，JMS和AMQP。JMS你可以類比為JDBC，搞了一套接口讓不同廠商來實現這個接口，但是這個協議設計的確實不夠優雅，因此就不介紹這個協議了，除非你用ActiveMQ，不然學了真沒啥用。詳細說一下AMQP協議，畢竟現在用RabbitMQ的公司還是很多的，要想學好RabbitMQ，AMQP協議是必須要清楚的。
AMQP協議模型
上圖是AMQP協議中一個消息的流轉過程，畫的的很清楚，不詳細介紹了。
AMQP核心概念
介紹一些AMQP協議常見的概念。
如果有用過ActiveMQ和RabbitMQ，對上面的名詞一定不會陌生。後面一篇文章就結合RabbitMQ來闡述上面的概念。
閱讀更多 Java識堂 的文章
