消息隊列是分布式應(yīng)用間交換信息的重要組件，消息隊列可駐留在內(nèi)存或磁盤上, 隊列可以存儲消息直到它們被應(yīng)用程序讀走。

通過消息隊列，應(yīng)用程序可以在不知道彼此位置的情況下獨立處理消息，或者在處理消息前不需要等待接收此消息。

所以消息隊列可以解決應(yīng)用解耦、異步消息、流量削鋒等問題，是實現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)中不可以或缺的一環(huán)。

現(xiàn)在比較常見的消息隊列產(chǎn)品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。

1 ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)，盡管JMS規(guī)范出臺已經(jīng)是很久的事情了，但是JMS在當(dāng)今的J2EE應(yīng)用中間仍然扮演著特殊的地位。

ActiveMQ特性如下：

⒈ 多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP

⒉ 完全支持JMS1.1和J2EE 1.4規(guī)范 （持久化，XA消息，事務(wù))

⒊ 對Spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性

⒋ 通過了常見J2EE服務(wù)器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上

⒌ 支持多種傳送協(xié)議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

⒍ 支持通過JDBC和journal提供高速的消息持久化

⒎ 從設(shè)計上保證了高性能的集群，客戶端-服務(wù)器，點對點

⒏ 支持Ajax

⒐ 支持與Axis的整合

⒑ 可以很容易得調(diào)用內(nèi)嵌JMS provider，進(jìn)行測試

2 RabbitMQ

RabbitMQ是流行的開源消息隊列系統(tǒng)，用erlang語言開發(fā)。RabbitMQ是AMQP（高級消息隊列協(xié)議）的標(biāo)準(zhǔn)實現(xiàn)。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，在易用性、擴展性、高可用性等方面表現(xiàn)不俗。

幾個重要概念：

Broker：簡單來說就是消息隊列服務(wù)器實體。

　　Exchange：消息交換機，它指定消息按什么規(guī)則，路由到哪個隊列。

　　Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。

　　Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來。

　　Routing Key：路由關(guān)鍵字，exchange根據(jù)這個關(guān)鍵字進(jìn)行消息投遞。

　　vhost：虛擬主機，一個broker里可以開設(shè)多個vhost，用作不同用戶的權(quán)限分離。

　　producer：消息生產(chǎn)者，就是投遞消息的程序。

　　consumer：消息消費者，就是接受消息的程序。

　　channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務(wù)。

消息隊列的使用過程，如下：

（1）客戶端連接到消息隊列服務(wù)器，打開一個channel。

（2）客戶端聲明一個exchange，并設(shè)置相關(guān)屬性。

（3）客戶端聲明一個queue，并設(shè)置相關(guān)屬性。

（4）客戶端使用routing key，在exchange和queue之間建立好綁定關(guān)系。

（5）客戶端投遞消息到exchange。

exchange接收到消息后，就根據(jù)消息的key和已經(jīng)設(shè)置的binding，進(jìn)行消息路由，將消息投遞到一個或多個隊列里。

3 ZeroMQ

號稱史上最快的消息隊列，它實際類似于Socket的一系列接口，他跟Socket的區(qū)別是：普通的socket是端到端的（1:1的關(guān)系），而ZMQ卻是可以N：M 的關(guān)系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協(xié)議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細(xì)節(jié)，讓你的網(wǎng)絡(luò)編程更為簡單。ZMQ用于node與node間的通信，node可以是主機或者是進(jìn)程。

引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內(nèi)核和主機盒之間彈性伸縮。ZMQ的明確目標(biāo)是“成為標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議棧的一部分，之后進(jìn)入Linux內(nèi)核”。現(xiàn)在還未看到它們的成功。但是，它無疑是極具前景的、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡單和有趣。”

特點是：

• 高性能，非持久化

• 跨平臺：支持Linux、Windows、OS X等

• 多語言支持； C、C++、Java、.NET、Python等30多種開發(fā)語言

• 可單獨部署或集成到應(yīng)用中使用

• 可作為Socket通信庫使用

與RabbitMQ相比，ZMQ并不像是一個傳統(tǒng)意義上的消息隊列服務(wù)器，事實上，它也根本不是一個服務(wù)器，更像一個底層的網(wǎng)絡(luò)通訊庫，在Socket API之上做了一層封裝，將網(wǎng)絡(luò)通訊、進(jìn)程通訊和線程通訊抽象為統(tǒng)一的API接口。支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三種基本模型和擴展模型。

ZeroMQ高性能設(shè)計要點：

1、無鎖的隊列模型

?? 對于跨線程間的交互（用戶端和session）之間的數(shù)據(jù)交換通道pipe，采用無鎖的隊列算法CAS；在pipe兩端注冊有異步事件，在讀或者寫消息到pipe的時，會自動觸發(fā)讀寫事件。

2、批量處理的算法

?? 對于傳統(tǒng)的消息處理，每個消息在發(fā)送和接收的時候，都需要系統(tǒng)的調(diào)用，這樣對于大量的消息，系統(tǒng)的開銷比較大，zeroMQ對于批量的消息，進(jìn)行了適應(yīng)性的優(yōu)化，可以批量的接收和發(fā)送消息。

3、多核下的線程綁定，無須CPU切換

?? 區(qū)別于傳統(tǒng)的多線程并發(fā)模式，信號量或者臨界區(qū)， zeroMQ充分利用多核的優(yōu)勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。

4 Kafka

Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)。 這種動作（網(wǎng)頁瀏覽，搜索和其他用戶的行動）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決。 對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的并行加載機制來統(tǒng)一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。

Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，有如下特性：

• 通過O(1)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對于即使數(shù)以TB的消息存儲也能夠保持長時間的穩(wěn)定性能。（文件追加的方式寫入數(shù)據(jù)，過期的數(shù)據(jù)定期刪除）

• 高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬的消息

• 支持通過Kafka服務(wù)器和消費機集群來分區(qū)消息

• 支持Hadoop并行數(shù)據(jù)加載

Kafka相關(guān)概念

• Broker

Kafka集群包含一個或多個服務(wù)器，這種服務(wù)器被稱為broker[5]

• Topic

每條發(fā)布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處）

• Partition

Parition是物理上的概念，每個Topic包含一個或多個Partition.

• Producer

負(fù)責(zé)發(fā)布消息到Kafka broker

• Consumer

消息消費者，向Kafka broker讀取消息的客戶端。

• Consumer Group

每個Consumer屬于一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬于默認(rèn)的group）。

一般應(yīng)用在大數(shù)據(jù)日志處理或?qū)崟r性（少量延遲），可靠性（少量丟數(shù)據(jù)）要求稍低的場景使用。

5 RocketMQ

RocketMQ是阿里開源的消息中間件，純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點。RocketMQ思路起源于Kafka，但并不是簡單的復(fù)制，它對消息的可靠傳輸及事務(wù)性做了優(yōu)化，目前在阿里集團被廣泛應(yīng)用于交易、充值、流計算、消息推送、日志流式處理、binglog分發(fā)等場景，支撐了阿里多次雙十一活動。

因為是阿里內(nèi)部從實踐到產(chǎn)品的產(chǎn)物，因此里面很多接口、api并不是很普遍適用。可靠性毋庸置疑，而且與Kafka一脈相承（甚至更優(yōu)），性能強勁，支持海量堆積。

6 Apollo

Apache ActiveMQ 是一個非常流行、強大、開源的消息和集成模式（Integration Patterns）服務(wù)器，速度快、支持多種跨語言客戶端和協(xié)議，易于使用企業(yè)集成模式（Enterprise Integration Patterns），擁有許多先進(jìn)的特性，完全支持JMS 1.1和J2EE 1.4規(guī)范。ActiveMQ 基于Apache 2.0許可。

Apollo 以 ActiveMQ原型為基礎(chǔ)，是一個更快、更可靠、更易于維護(hù)的消息代理工具。Apache 號稱 Apollo 為最快、最強健的STOMP（Streaming Text Orientated Message Protocol，流文本定向消息協(xié)議）服務(wù)器。
Apollo的特性如下：

• 支持Stomp 1.0和Stomp 1.1協(xié)議
• 主題和隊列
• 隊列瀏覽器
• 主題持久訂閱
• 鏡像隊列
• 可靠的消息傳遞
• 消息過期和交換
• 消息選擇器
• JAAS驗證
• 基于ACL的授權(quán)
• 支持SSL/TLS，證書驗證
• REST Management API

選擇哪個中間件？

到底應(yīng)該哪個方案，還是要看具體的需求。在我們的設(shè)計中，MQ的功能與業(yè)務(wù)無關(guān)，因此優(yōu)先考慮使用已有的中間件搭建。那么具本選擇哪個中間件呢？先來梳理下我們對MQ的需求：

功能需求

如前文所述，除了最基本生產(chǎn)消費模型，還需要MQ能支持REQUEST-REPLY模型，以提供對同步調(diào)用的支持。 此外，如果MQ能提供PUBLISH-SUBSCRIBE模型，則事件代理的實現(xiàn)可以更加簡單。

性能需求

考慮未來一到兩年內(nèi)產(chǎn)品的發(fā)展，消息隊列的呑吐量預(yù)計不會超過 1W qps，但由單條消息延遲要求較高，希望盡量的短。

可用性需求

因為是在線服務(wù)，因此需要較高的可用性，但充許有少量消息丟失。

易用性需求

包括學(xué)習(xí)成本、初期的開發(fā)部署成本、日常的運維成本等。

橫向?qū)Ρ?/h5>

ActiveMQ與RabbitMQ在很多方面都很相似，但ActiveMQ對非JAVA生態(tài)的支持不及rabbitMQ, 加之精力有限，因此本文重點關(guān)注RabbitMQ。

特性
ActiveMQ
RabbitMQ
Kafka
RocketMQ

PRODUCER-COMSUMER
支持
支持
支持
支持

PUBLISH-SUBSCRIBE
支持
支持
支持
支持

REQUEST-REPLY
支持
支持
-
支持

API完備性
高
高
高
低（靜態(tài)配置）

多語言支持
支持，JAVA優(yōu)先
語言無關(guān)
支持，JAVA優(yōu)先
支持

單機呑吐量
萬級
萬級
十萬級
單機萬級

消息延遲
-
微秒級
毫秒級
-

可用性
高（主從）
高（主從）
非常高（分布式）
高

消息丟失
-
低
理論上不會丟失
-

消息重復(fù)
-
可控制
理論上會有重復(fù)
-

文檔的完備性
高
高
高
中

提供快速入門
有
有
有
無

首次部署難度
-
低
中
高

注： - 表示尚未查找到準(zhǔn)確數(shù)據(jù)

總結(jié)

消息隊列的選型需要根據(jù)具體應(yīng)用需求而定，ZeroMQ小而美，RabbitMQ大而穩(wěn)，Kakfa和RocketMQ快而強勁。

RocketMQ雖然目前還很多不完善，但是一旦在Apache孵化成為頂級項目，前途也是不可限量的。

參考資料

https://blog.csdn.net/cws1214/article/details/52922267

https://blog.csdn.net/liuxinghao/article/details/60875715

https://blog.csdn.net/pkueecser/article/details/50613989

轉(zhuǎn)載于:https://www.cnblogs.com/willem-xin/p/10258225.html

總結(jié)

以上是生活随笔為你收集整理的常用消息队列介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。