文章大綱
一、什么是消息中間件
二、消息中間件組成
三、消息隊列的的傳輸模式
四、消息中間件的優(yōu)勢
五、消息中間件應(yīng)用場景
六、消息中間件常用協(xié)議
七、常見消息中間件介紹與比較
八、參考文章
一、什么是消息中間件
??消息隊列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內(nèi)部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當(dāng)今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。
二、消息中間件組成
1. Broker
消息服務(wù)器，為server提供消息核心服務(wù)
2. Producer
消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給broker
3. Consumer
消息消費者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理
4. Topic
主題，發(fā)布訂閱模式下的消息統(tǒng)一匯集地，不同生產(chǎn)者向topic發(fā)送消息，由MQ服務(wù)器分發(fā)到不同的訂閱者，實現(xiàn)消息的廣播
5. Queue
隊列，PTP模式下，特定生產(chǎn)者向特定queue發(fā)送消息，消費者訂閱特定的queue完成指定消息的接收
6. Message
消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實現(xiàn)消息的傳輸
三、消息隊列的的傳輸模式
1. 點對點
點對點模型 用于 消息生產(chǎn)者 和 消息消費者 之間 點到點 的通信。消息生產(chǎn)者將消息發(fā)送到由某個名字標(biāo)識的特定消費者。這個名字實際上對于消費服務(wù)中的一個 隊列（Queue），在消息傳遞給消費者之前它被 存儲 在這個隊列中。隊列消息 可以放在 內(nèi)存 中也可以 持久化，以保證在消息服務(wù)出現(xiàn)故障時仍然能夠傳遞消息。
傳統(tǒng)的點對點消息中間件通常由 消息隊列服務(wù)、消息傳遞服務(wù)、消息隊列 和 消息應(yīng)用程序接口 API 組成，其典型的結(jié)構(gòu)如下圖所示。
特點
每個消息只用一個消費者；
發(fā)送者和接受者沒有時間依賴；
接受者確認(rèn)消息接受和處理成功。
示意圖如下所示
2. 發(fā)布/訂閱模型（Pub/Sub）
發(fā)布者/訂閱者 模型支持向一個特定的 消息主題 生產(chǎn)消息。0 或 多個訂閱者 可能對接收來自 特定消息主題 的消息感興趣。
在這種模型下，發(fā)布者和訂閱者彼此不知道對方，就好比是匿名公告板。這種模式被概況為：多個消費者可以獲得消息，在 發(fā)布者 和 訂閱者 之間存在 時間依賴性。發(fā)布者需要建立一個 訂閱（subscription），以便能夠消費者訂閱。訂閱者 必須保持 持續(xù)的活動狀態(tài) 并 接收消息。
在這種情況下，在訂閱者 未連接時，發(fā)布的消息將在訂閱者 重新連接 時 重新發(fā)布，如下圖所示：
特性
每個消息可以有多個訂閱者；
客戶端只有訂閱后才能接收到消息；
持久訂閱和非持久訂閱。
注意
發(fā)布者和訂閱者有時間依賴：接受者和發(fā)布者只有建立訂閱關(guān)系才能收到消息；
持久訂閱：訂閱關(guān)系建立后，消息就不會消失，不管訂閱者是否都在線；
非持久訂閱：訂閱者為了接受消息，必須一直在線。當(dāng)只有一個訂閱者時約等于點對點模式
四、消息中間件的優(yōu)勢
1. 系統(tǒng)解耦
交互系統(tǒng)之間沒有直接的調(diào)用關(guān)系，只是通過消息傳輸，故系統(tǒng)侵入性不強(qiáng)，耦合度低。
2. 提高系統(tǒng)響應(yīng)時間
例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態(tài)、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構(gòu)設(shè)計，就可將緊急重要（需要立刻響應(yīng)）的業(yè)務(wù)放到該調(diào)用方法中，響應(yīng)要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。
3. 為大數(shù)據(jù)處理架構(gòu)提供服務(wù)
通過消息作為整合，大數(shù)據(jù)的背景下，消息隊列還與實時處理架構(gòu)整合，為數(shù)據(jù)處理提供性能支持。
4. Java消息服務(wù)——JMS
Java消息服務(wù)（Java Message Service，JMS）應(yīng)用程序接口是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。
JMS中的P2P和Pub/Sub消息模式：點對點（point to point， queue）與發(fā)布訂閱（publish/subscribe，topic）最初是由JMS定義的。這兩種模式主要區(qū)別或解決的問題就是發(fā)送到隊列的消息能否重復(fù)消費(多訂閱)。
五、消息中間件應(yīng)用場景
當(dāng)你需要使用 消息隊列 時，首先需要考慮它的必要性?？梢允褂孟㈥犃械膱鼍坝泻芏啵畛Ｓ玫膸追N，是做 應(yīng)用程序松耦合、異步處理模式、發(fā)布與訂閱、最終一致性、錯峰流控 和 日志緩沖 等。反之，如果需要 強(qiáng)一致性，關(guān)注業(yè)務(wù)邏輯的處理結(jié)果，則使用 RPC 顯得更為合適。
1. 異步處理
1.1 介紹
有些業(yè)務(wù)不想也不需要立即處理消息。消息隊列提供了異步處理機(jī)制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。
1.2 具體場景
用戶為了使用某個應(yīng)用，進(jìn)行注冊，系統(tǒng)需要發(fā)送注冊郵件并驗證短信。對這兩個操作的處理方式有兩種：串行及并行。
（1）串行方式：新注冊信息生成后，先發(fā)送注冊郵件，再發(fā)送驗證短信；
在這種方式下，需要最終發(fā)送驗證短信后再返回給客戶端。
（2）并行處理：新注冊信息寫入后，由發(fā)短信和發(fā)郵件并行處理；
在這種方式下，發(fā)短信和發(fā)郵件 需處理完成后再返回給客戶端。
假設(shè)以上三個子系統(tǒng)處理的時間均為50ms，且不考慮網(wǎng)絡(luò)延遲，則總的處理時間：
串行：50+50+50=150ms 并行：50+50 = 100ms
若使用消息隊列：
并在寫入消息隊列后立即返回成功給客戶端，則總的響應(yīng)時間依賴于寫入消息隊列的時間，而寫入消息隊列的時間本身是可以很快的，基本可以忽略不計，因此總的處理時間相比串行提高了2倍，相比并行提高了一倍；
2. 應(yīng)用耦合
2.1 介紹
交互系統(tǒng)之間沒有直接的調(diào)用關(guān)系，只是通過消息傳輸，故系統(tǒng)侵入性不強(qiáng)，耦合度低。
2.2 具體場景
用戶使用QQ相冊上傳一張圖片，人臉識別系統(tǒng)會對該圖片進(jìn)行人臉識別，一般的做法是，服務(wù)器接收到圖片后，圖片上傳系統(tǒng)立即調(diào)用人臉識別系統(tǒng)，調(diào)用完成后再返回成功，如下圖所示：
該方法有如下缺點：
（1）人臉識別系統(tǒng)被調(diào)失敗，導(dǎo)致圖片上傳失敗；
（2）延遲高，需要人臉識別系統(tǒng)處理完成后，再返回給客戶端，即使用戶并不需要立即知道結(jié)果；
（3）圖片上傳系統(tǒng)與人臉識別系統(tǒng)之間互相調(diào)用，需要做耦合；
若使用消息隊列：
客戶端上傳圖片后，圖片上傳系統(tǒng)將圖片信息如uin、批次寫入消息隊列，直接返回成功；而人臉識別系統(tǒng)則定時從消息隊列中取數(shù)據(jù)，完成對新增圖片的識別。
此時圖片上傳系統(tǒng)并不需要關(guān)心人臉識別系統(tǒng)是否對這些圖片信息的處理、以及何時對這些圖片信息進(jìn)行處理。事實上，由于用戶并不需要立即知道人臉識別結(jié)果，人臉識別系統(tǒng)可以選擇不同的調(diào)度策略，按照閑時、忙時、正常時間，對隊列中的圖片信息進(jìn)行處理。
3. 流量削峰和流控
3.1 介紹
當(dāng)上下游系統(tǒng) 處理能力存在差距的時候，利用 消息隊列 做一個通用的 “漏斗”，進(jìn)行 限流控制。在下游有能力處理的時候，再進(jìn)行分發(fā)。
3.2 具體場景
用戶在支付系統(tǒng)成功結(jié)賬后，訂單系統(tǒng)會通過短信系統(tǒng)向用戶推送扣費通知。短信系統(tǒng) 可能由于 短板效應(yīng)，速度卡在 網(wǎng)關(guān) 上（每秒幾百次請求），跟 前端的并發(fā)量 不是一個數(shù)量級。于是，就造成 支付系統(tǒng) 和 短信系統(tǒng) 的處理能力出現(xiàn)差異化。
然而用戶晚上個半分鐘左右收到短信，一般是不會有太大問題的。如果沒有消息隊列，兩個系統(tǒng)之間通過 協(xié)商、滑動窗口 等復(fù)雜的方案也不是說不能實現(xiàn)。但 系統(tǒng)復(fù)雜性 指數(shù)級增長，勢必在 上游 或者 下游 做 存儲，并且要處理 定時、擁塞 等一系列問題。而且每當(dāng)有 處理能力有差距 的時候，都需要 單獨 開發(fā)一套邏輯來維護(hù)這套邏輯。
所以，利用中間系統(tǒng)轉(zhuǎn)儲兩個系統(tǒng)的通信內(nèi)容，并在下游系統(tǒng)有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。
應(yīng)用案例
（1）把消息隊列當(dāng)成可靠的 消息暫存地，進(jìn)行一定程度的 消息堆積；
（2）定時進(jìn)行消息投遞，比如模擬 用戶秒殺 訪問，進(jìn)行 系統(tǒng)性能壓測。
4. 消息驅(qū)動的系統(tǒng)
具體場景
用戶新上傳了一批照片， 人臉識別系統(tǒng)需要對這個用戶的所有照片進(jìn)行聚類，聚類完成后由對賬系統(tǒng)重新生成用戶的人臉?biāo)饕?加快查詢)。這三個子系統(tǒng)間由消息隊列連接起來，前一個階段的處理結(jié)果放入隊列中，后一個階段從隊列中獲取消息繼續(xù)處理。
該方法有如下優(yōu)點：
（1）避免了直接調(diào)用下一個系統(tǒng)導(dǎo)致當(dāng)前系統(tǒng)失?。?br>
（2）每個子系統(tǒng)對于消息的處理方式可以更為靈活，可以選擇收到消息時就處理，可以選擇定時處理，也可以劃分時間段按不同處理速度處理；
5. 日志處理
將消息隊列用在 日志處理 中，比如 Kafka 的應(yīng)用，解決 海量日志 傳輸和緩沖的問題。
應(yīng)用案例
把日志進(jìn)行集中收集，用于計算 PV、用戶行為分析 等等。
6. 順序保證
在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。
7. 消息通訊
消息隊列一般都內(nèi)置了 高效的通信機(jī)制，因此也可以用于單純的 消息通訊，比如實現(xiàn) 點對點消息隊列 或者 聊天室 等。
六、消息中間件常用協(xié)議
1. AMQP協(xié)議
AMQP即Advanced Message Queuing Protocol,一個提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級消息隊列協(xié)議,是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。
優(yōu)點：可靠、通用
2. MQTT協(xié)議
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發(fā)的一個即時通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和致動器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。
優(yōu)點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統(tǒng)
3. STOMP協(xié)議
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設(shè)計的簡單文本協(xié)議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進(jìn)行交互。
優(yōu)點：命令模式（非topic\queue模式）
4. XMPP協(xié)議
XMPP（可擴(kuò)展消息處理現(xiàn)場協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴(kuò)展標(biāo)記語言（XML）的協(xié)議，多用于即時消息（IM）以及在線現(xiàn)場探測。適用于服務(wù)器之間的準(zhǔn)即時操作。核心是基于XML流傳輸，這個協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時消息，即使其操作系統(tǒng)和瀏覽器不同。
優(yōu)點：通用公開、兼容性強(qiáng)、可擴(kuò)展、安全性高，但XML編碼格式占用帶寬大
5. 其他基于TCP/IP自定義的協(xié)議
有些特殊框架（如：redis、kafka、zeroMq等）根據(jù)自身需要未嚴(yán)格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進(jìn)行傳輸，實現(xiàn)了MQ的功能。
七、常見消息中間件介紹與比較
1. 中間件介紹
1.1 ActiveMQ
簡介
ActiveMQ 是由 Apache 出品，ActiveMQ 是一個完全支持JMS1.1 和 J2EE 1.4 規(guī)范的 JMS Provider 實現(xiàn)。它非?？焖?，支持 多種語言的客戶端 和 協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級功能。
主要特性
（1）服從JMS規(guī)范：JMS 規(guī)范提供了良好的標(biāo)準(zhǔn)和保證，包括：同步 或 異步 的消息分發(fā)，一次和僅一次的消息分發(fā)，消息接收 和 訂閱 等等。遵從 JMS 規(guī)范的好處在于，不論使用什么 JMS 實現(xiàn)提供者，這些基礎(chǔ)特性都是可用的；
（2）連接靈活性：ActiveMQ 提供了廣泛的 連接協(xié)議，支持的協(xié)議有：HTTP/S，IP 多播，SSL，TCP，UDP 等等。對眾多協(xié)議的支持讓 ActiveMQ 擁有了很好的靈活性；
（3）支持的協(xié)議種類多：OpenWire、STOMP、REST、XMPP、AMQP；
（4）持久化插件和安全插件：ActiveMQ 提供了 多種持久化 選擇。而且，ActiveMQ 的安全性也可以完全依據(jù)用戶需求進(jìn)行 自定義鑒權(quán) 和 授權(quán)；
（5）支持的客戶端語言種類多：除了 Java 之外，還有：C/C++，.NET，Perl，PHP，Python，Ruby；
（6）代理集群：多個 ActiveMQ 代理 可以組成一個 集群 來提供服務(wù)；
（7）異常簡單的管理：ActiveMQ 是以開發(fā)者思維被設(shè)計的。所以，它并不需要專門的管理員，因為它提供了簡單又使用的管理特性。有很多中方法可以 監(jiān)控 ActiveMQ 不同層面的數(shù)據(jù)，包括使用在 JConsole 或者在 ActiveMQ 的 Web Console 中使用 JMX。通過處理 JMX 的告警消息，通過使用 命令行腳本，甚至可以通過監(jiān)控各種類型的 日志。
部署環(huán)境
ActiveMQ 可以運行在 Java 語言所支持的平臺之上。使用 ActiveMQ 需要：
（1）Java JDK
（2）ActiveMQ 安裝包
優(yōu)點
（1）跨平臺 (JAVA 編寫與平臺無關(guān)，ActiveMQ 幾乎可以運行在任何的 JVM 上)；
（2）可以用 JDBC：可以將 數(shù)據(jù)持久化 到數(shù)據(jù)庫。雖然使用 JDBC 會降低 ActiveMQ 的性能，但是數(shù)據(jù)庫一直都是開發(fā)人員最熟悉的存儲介質(zhì)；
（3）支持 JMS 規(guī)范：支持 JMS 規(guī)范提供的 統(tǒng)一接口;
（4）支持 自動重連 和 錯誤重試機(jī)制；
（5）有安全機(jī)制：支持基于 shiro，jaas 等多種 安全配置機(jī)制，可以對 Queue/Topic 進(jìn)行 認(rèn)證和授權(quán)；
（6）監(jiān)控完善：擁有完善的 監(jiān)控，包括 Web Console，JMX，Shell 命令行，Jolokia 的 RESTful API；
9）7界面友善：提供的 Web Console 可以滿足大部分情況，還有很多 第三方的組件 可以使用，比如 hawtio；
缺點
（1）社區(qū)活躍度不及 RabbitMQ 高；
（2）根據(jù)其他用戶反饋，會出莫名其妙的問題，會 丟失消息；
（3）目前重心放到 activemq 6.0 產(chǎn)品 Apollo，對 5.x 的維護(hù)較少；
（4）不適合用于 上千個隊列 的應(yīng)用場景；
1.2 RabbitMQ
RabbitMQ 于 2007 年發(fā)布，是一個在 AMQP (高級消息隊列協(xié)議)基礎(chǔ)上完成的，可復(fù)用的企業(yè)消息系統(tǒng)，是當(dāng)前最主流的消息中間件之一。
主要特性
（1）可靠性：提供了多種技術(shù)可以讓你在 性能 和 可靠性 之間進(jìn)行 權(quán)衡。這些技術(shù)包括 持久性機(jī)制、投遞確認(rèn)、發(fā)布者證實 和 高可用性機(jī)制；
（2）靈活的路由：消息在到達(dá)隊列前是通過 交換機(jī) 進(jìn)行 路由 的。RabbitMQ 為典型的路由邏輯提供了 多種內(nèi)置交換機(jī) 類型。如果你有更復(fù)雜的路由需求，可以將這些交換機(jī)組合起來使用，你甚至可以實現(xiàn)自己的交換機(jī)類型，并且當(dāng)做 RabbitMQ 的 插件 來使用；
（3）消息集群：在相同局域網(wǎng)中的多個 RabbitMQ 服務(wù)器可以 聚合 在一起，作為一個獨立的邏輯代理來使用；
（4）隊列高可用：隊列可以在集群中的機(jī)器上 進(jìn)行鏡像，以確保在硬件問題下還保證 消息安全；
（5）支持多種協(xié)議：支持 多種消息隊列協(xié)議；
（6）支持多種語言：用 Erlang 語言編寫，支持只要是你能想到的 所有編程語言；
（7）管理界面： RabbitMQ 有一個易用的 用戶界面，使得用戶可以 監(jiān)控 和 管理 消息 Broker 的許多方面；
（8）跟蹤機(jī)制：如果 消息異常，RabbitMQ 提供消息跟蹤機(jī)制，使用者可以找出發(fā)生了什么；
（9）插件機(jī)制：提供了許多 插件，來從多方面進(jìn)行擴(kuò)展，也可以編寫自己的插件。
部署環(huán)境
RabbitMQ 可以運行在 Erlang 語言所支持的平臺之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。使用 RabbitMQ 需要：
（1）ErLang 語言包
（2）RabbitMQ 安裝包
優(yōu)點
（1）由于 Erlang 語言的特性，消息隊列性能較好，支持 高并發(fā)；
（2）健壯、穩(wěn)定、易用、跨平臺、支持 多種語言、文檔齊全；
（3）有消息 確認(rèn)機(jī)制 和 持久化機(jī)制，可靠性高；
（4）高度可定制的 路由；
（5）管理界面 較豐富，在互聯(lián)網(wǎng)公司也有較大規(guī)模的應(yīng)用，社區(qū)活躍度高。
缺點
（1）盡管結(jié)合 Erlang 語言本身的并發(fā)優(yōu)勢，性能較好，但是不利于做 二次開發(fā)和維護(hù)；
（2）實現(xiàn)了 代理架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在 中央節(jié)點 上排隊。此特性使得 RabbitMQ 易于使用和部署，但是使得其 運行速度較慢，因為中央節(jié)點 增加了延遲，消息封裝后 也比較大；
（3）需要學(xué)習(xí) 比較復(fù)雜 的 接口和協(xié)議，學(xué)習(xí)和維護(hù)成本較高。
1.3 RocketMQ
簡介
RocketMQ 出自 阿里 的開源產(chǎn)品，用 Java 語言實現(xiàn)，在設(shè)計時參考了 Kafka，并做出了自己的一些改進(jìn)，消息可靠性上 比 Kafka 更好。RocketMQ 在阿里內(nèi)部被廣泛應(yīng)用在 訂單，交易，充值，流計算，消息推送，日志流式處理，binglog 分發(fā) 等場景。
主要特性
（1）基于 隊列模型：具有 高性能、高可靠、高實時、分布式 等特點；
（2）Producer、Consumer、隊列 都支持 分布式；
（3）Producer 向一些隊列輪流發(fā)送消息，隊列集合 稱為 Topic。Consumer 如果做 廣播消費，則一個 Consumer 實例消費這個 Topic 對應(yīng)的 所有隊列；如果做 集群消費，則 多個 Consumer 實例 平均消費 這個 Topic 對應(yīng)的隊列集合；
（4）能夠保證 嚴(yán)格的消息順序；
（5）提供豐富的 消息拉取模式；
（6）高效的訂閱者 水平擴(kuò)展能力；
（7）實時 的 消息訂閱機(jī)制；
（8）億級 消息堆積 能力；
（9）較少的外部依賴。
部署環(huán)境
RocketMQ 可以運行在 Java 語言所支持的平臺之上。使用 RocketMQ 需要：
（1）Java JDK
（2）安裝 git、Maven
（3）RocketMQ 安裝包
優(yōu)點
（1）單機(jī) 支持 1 萬以上 持久化隊列；
（2）RocketMQ 的所有消息都是 持久化的，先寫入系統(tǒng) PAGECACHE，然后 刷盤，可以保證 內(nèi)存 與 磁盤 都有一份數(shù)據(jù)，而 訪問 時，直接 從內(nèi)存讀取。
（3）模型簡單，接口易用（JMS 的接口很多場合并不太實用）；
（4）性能非常好，可以允許 大量堆積消息 在 Broker 中；
（5）支持 多種消費模式，包括 集群消費、廣播消費等；
（6）各個環(huán)節(jié) 分布式擴(kuò)展設(shè)計，支持 主從 和 高可用；
（7）開發(fā)度較活躍，版本更新很快。
缺點
（1）支持的 客戶端語言 不多，目前是 Java 及 C++，其中 C++ 還不成熟；
（2）RocketMQ 社區(qū)關(guān)注度及成熟度也不及前兩者；
（3）沒有 Web 管理界面，提供了一個 CLI (命令行界面) 管理工具帶來 查詢、管理 和 診斷各種問題；
（4）沒有在 MQ 核心里實現(xiàn) JMS 等接口；
1.4 Kafka
簡介
Apache Kafka 是一個 分布式消息發(fā)布訂閱 系統(tǒng)。它最初由 LinkedIn 公司基于獨特的設(shè)計實現(xiàn)為一個 分布式的日志提交系統(tǒng) (a distributed commit log)，之后成為 Apache 項目的一部分。Kafka 性能高效、可擴(kuò)展良好 并且 可持久化。它的 分區(qū)特性，可復(fù)制 和 可容錯 都是其不錯的特性。
主要特性
（1）快速持久化：可以在 O(1) 的系統(tǒng)開銷下進(jìn)行 消息持久化；
（2）高吞吐：在一臺普通的服務(wù)器上既可以達(dá)到 10W/s 的 吞吐速率；
（3）完全的分布式系統(tǒng)：Broker、Producer 和 Consumer 都原生自動支持 分布式，自動實現(xiàn) 負(fù)載均衡；
（4）支持 同步 和 異步 復(fù)制兩種 高可用機(jī)制；
（5）支持 數(shù)據(jù)批量發(fā)送 和 拉?。?br>
（6）零拷貝技術(shù)(zero-copy)：減少 IO 操作步驟，提高 系統(tǒng)吞吐量；
（7）數(shù)據(jù)遷移、擴(kuò)容 對用戶透明；
（8）無需停機(jī) 即可擴(kuò)展機(jī)器；
（9）其他特性：豐富的 消息拉取模型、高效 訂閱者水平擴(kuò)展、實時的 消息訂閱、億級的 消息堆積能力、定期刪除機(jī)制；
部署環(huán)境
使用 Kafka 需要：
（1）Java JDK
（2）Kafka 安裝包
優(yōu)點
（1）客戶端語言豐富：支持 Java、.Net、PHP、Ruby、Python、Go 等多種語言；
（2）高性能：單機(jī)寫入 TPS 約在 100 萬條/秒，消息大小 10 個字節(jié)；
（3）提供 完全分布式架構(gòu)，并有 replica 機(jī)制，擁有較高的 可用性 和 可靠性，理論上支持 消息無限堆積；
（4）支持批量操作；
（5）消費者 采用 Pull 方式獲取消息。消息有序，通過控制 能夠保證所有消息被消費且僅被消費 一次；
（6）有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager；
（7）在日志領(lǐng)域 比較成熟，被多家公司和多個開源項目使用。
缺點
（1）Kafka 單機(jī)超過 64 個 隊列/分區(qū) 時，Load 時會發(fā)生明顯的飆高現(xiàn)象。隊列 越多，負(fù)載 越高，發(fā)送消息 響應(yīng)時間變長；
（2）使用 短輪詢方式，實時性 取決于 輪詢間隔時間；
（3）消費失敗 不支持重試；
（4）支持 消息順序，但是 一臺代理宕機(jī) 后，就會產(chǎn)生 消息亂序；
（5）社區(qū)更新較慢。
2. 中間件比較
2.1 比較一
ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。這個結(jié)論來自于以下這篇文章。
http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
測試環(huán)境：
Model: Dell Studio 1749
CPU: Intel Core i3 @ 2.40 GH
RAM: 4 Gb
OS: Windows 7 64 bits
其中包括持久化消息和瞬時消息的測試。注意這篇文章里面提到的MQ，都是采用默認(rèn)配置的，并無調(diào)優(yōu)。
更多的統(tǒng)計圖請參看我提供的文章url。
2.2 比較二
ZeroMq 最好，RabbitMq次之， ActiveMq最差。這個結(jié)論來自于一下這篇文章。http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html
顯示的是發(fā)送和接受的每秒鐘的消息數(shù)。整個過程共產(chǎn)生1百萬條1K的消息。測試的執(zhí)行是在一個Windows Vista上進(jìn)行的。
2.3 持久化消息比較
zeroMq不支持，activeMq和rabbitMq都支持。持久化消息主要是指：MQ down或者M(jìn)Q所在的服務(wù)器down了，消息不會丟失的機(jī)制。
2.4 技術(shù)點：可靠性、靈活的路由、集群、事務(wù)、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系統(tǒng)、社區(qū)
RabbitMq最好，ActiveMq次之，ZeroMq最差。當(dāng)然ZeroMq也可以做到，不過自己必須手動寫代碼實現(xiàn)，代碼量不小。尤其是可靠性中的：持久性、投遞確認(rèn)、發(fā)布者證實和高可用性。所以在可靠性和可用性上，RabbitMQ是首選，雖然ActiveMQ也具備，但是它性能不及RabbitMQ。
2.5 高并發(fā)
從實現(xiàn)語言來看，RabbitMQ最高，原因是它的實現(xiàn)語言是天生具備高并發(fā)高可用的erlang語言。
2.6 總體比較
結(jié)論：
（1）Kafka 在于 分布式架構(gòu)，RabbitMQ 基于 AMQP 協(xié)議 來實現(xiàn)，RocketMQ 的思路來源于 Kafka，改成了 主從結(jié)構(gòu)，在 事務(wù)性 和 可靠性 方面做了優(yōu)化。廣泛來說，電商、金融 等對 事務(wù)一致性 要求很高的，可以考慮 RabbitMQ 和 RocketMQ，對 性能要求高 的可考慮 Kafka。
（2）按照目前網(wǎng)絡(luò)上的資料，RabbitMQ、activeMQ、zeroMQ三者中，綜合來看，RabbitMQ是首選，但是activeMQ與Java結(jié)合度比較好。
