前言
趁着國慶的空餘時間寫了一個RabbitMQ的專欄，不知道你們玩的開心不，我方正假期的一大半時間都去參加婚禮了，今年國慶結婚的同窗好多啊git
github地址：https://github.com/erlieStar/rabbitmq-examples
github
可能你在沒學消息中間件以前都已經聽過不少概念了，JMS，AMQP，ActiveMQ，RabbitMQ，Kafka，RocketMQ，一個消息中間件怎麼能搞出怎麼多概念？亂不亂啊，
別煩，本文從歷史的角度幫你理清這些MQ和協議之間的關係。數據庫
什麼是消息中間件？
消息中間件屬於分佈式系統中的一個子系統，關注於數據的發送和接收，利用高效可靠的消息傳遞機制對分佈式系統中的其他各個子系統經進行集成編程
消息中間件的使用場景
1.異步處理
非核心流程異步化，提升系統響應性能
服務器
原來用戶註冊一下可能得依次寫數據庫，發送郵件和短信後，才能提示用戶註冊成功
如今只要寫數據庫，寫消息隊列後就直接提示用戶註冊成功，發送郵件和短信是異步處理，提升了響應速度
2.應用解耦
系統不是強耦合，消息接受者能夠隨意增長，而不須要修改消息發送者的代碼。消息發送者的成功不依賴消息接受者微信
若是庫存系統出了問題，用戶就不能正常下單，這是不合理的。能夠經過消息隊列來解耦。
當有新的系統如廣告系統對用戶的訂單也感興趣的時候，只須要從消息隊列中拿消息便可，訂單系統徹底不用改變
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.在 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 社區活躍度相對較爲通常，不過也還能夠，文檔相對來講簡單一些。
Kafka 的特色其實很明顯，就是僅僅提供較少的核心功能，可是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，並且分佈式能夠任意擴展。同時 Kafka 最好是支撐較少的 topic 數量便可，保證其超高吞吐量。Kafka 惟一的一點劣勢是有可能消息重複消費，那麼對數據準確性會形成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響能夠忽略。Kafka自然適合大數據實時計算以及日誌收集。
消息模型
若是讓你設計一個消息隊列？你會怎麼實現呢？
可能你立馬就會想到用隊列，一邊放，一邊取。這其實就是消息隊列常見的一種消息模型，隊列模型
因此一個簡單的消息隊列用Redis中的List就能實現。固然Redis5.0版本以後針對消息隊列這種場景專門設計了一個數據結構Streams。
隊列模型有哪些缺點呢？
若是將一類消息發送給不一樣的消費者，每一個消費者都要接收全量的消息，此時就很不方便。由於你要將相同的消息發送到不一樣的隊列，多一個消費者就得多發一份隊列。這樣生產者必須知道有多少個消費者，不利於解耦。
那麼該如何解決這個問題呢？
想一想RabbitMQ的結構圖
RabbitMQ並非直接把消息發送到隊列中的，而是發送到Exchange中，Exchange和Queue進行關聯，消息由Exchange根據規則發送到對應的隊列。這樣生產者和消費者完成了解耦。
還有哪一種方式能解決這種多消費者的問題呢？
答對了，就是發佈訂閱模型
RocketMQ和Kafka都是基於發佈訂閱模型實現的，RocketMQ的消息模型圖以下
生產者是發佈者，消費者是訂閱者，消息是主題
爲了提升消費的並行度，一類消息會被分發到多個隊列中，在RocketMQ中叫Queue，在Kafka中叫作Partition（分區），都是相似的概念。
AMQP協議詳解
前面說到消息中間件有2種協議，JMS和AMQP。JMS你能夠類比爲JDBC，搞了一套接口讓不一樣廠商來實現這個接口，可是這個協議設計的確實不夠優雅，所以就不介紹這個協議了，除非你用ActiveMQ，否則學了真沒啥用。詳細說一下AMQP協議，畢竟如今用RabbitMQ的公司仍是不少的，要想學好RabbitMQ，AMQP協議是必需要清楚的。
上圖是AMQP協議中一個消息的流轉過程，畫的的很清楚，不詳細介紹了。
AMQP核心概念
介紹一些AMQP協議常見的概念。
| 概念 | 解釋 |
|---|---|
| Server | 又稱Broker，接受客戶端的鏈接，實現AMQP實體服務 |
| Connection | 一個網絡鏈接，好比TCP/IP套接字鏈接 |
| Channel | 多路複用鏈接中的一條獨立的雙向數據流通道。爲會話提供物理傳輸介質 |
| Message | 消息，服務器和應用程序之間傳送的數據，由Properties和Body組成。Properties能夠對消息進行修飾，好比消息的優先級，延遲等高級特性，Body則就是消息體內容 |
| Virtual Host | 虛擬地址，用於進行邏輯隔離，最上層的消息路由。一個Virtual Host裏面能夠有若干個Exchange和Queue，同一個Virtual Host裏面不能有相同名稱的Exchange或Queue |
| Binding | 消息隊列和交換器之間的關聯 |
| Routing Key | 一個消息頭，交換器能夠用這個消息頭決定如何路由某條消息 |
| Message Queue | 消息隊列，用來保存消息直到發送給消費者 |
若是有用過ActiveMQ和RabbitMQ，對上面的名詞必定不會陌生。後面一篇文章就結合RabbitMQ來闡述上面的概念。
本文分享自微信公衆號 - Java識堂（erlieStar）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。