消息隊列是分佈式應用間交換信息的重要組件,消息隊列可駐留在內存或磁盤上, 隊列能夠存儲消息直到它們被應用程序讀走。node
經過消息隊列,應用程序能夠在不知道彼此位置的狀況下獨立處理消息,或者在處理消息前不須要等待接收此消息。算法
因此消息隊列能夠解決應用解耦、異步消息、流量削鋒等問題,是實現高性能、高可用、可伸縮和最終一致性架構中不能夠或缺的一環。apache
如今比較常見的消息隊列產品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。編程
ActiveMQ 是Apache出品,最流行的,能力強勁的開源消息總線。ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已是好久的事情了,可是JMS在當今的J2EE應用中間仍然扮演着特殊的地位。api
ActiveMQ特性以下:瀏覽器
⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP服務器
⒉ 徹底支持JMS1.1和J2EE 1.4規範 (持久化,XA消息,事務)網絡
⒊ 對Spring的支持,ActiveMQ能夠很容易內嵌到使用Spring的系統裏面去,並且也支持Spring2.0的特性session
⒋ 經過了常見J2EE服務器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試,其中經過JCA 1.5 resource adaptors的配置,可讓ActiveMQ能夠自動的部署到任何兼容J2EE 1.4 商業服務器上數據結構
⒌ 支持多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持經過JDBC和journal提供高速的消息持久化
⒎ 從設計上保證了高性能的集羣,客戶端-服務器,點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 能夠很容易得調用內嵌JMS provider,進行測試
RabbitMQ是流行的開源消息隊列系統,用erlang語言開發。RabbitMQ是AMQP(高級消息隊列協議)的標準實現。支持多種客戶端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX,持久化。用於在分佈式系統中存儲轉發消息,在易用性、擴展性、高可用性等方面表現不俗。
幾個重要概念:
Broker:簡單來講就是消息隊列服務器實體。
Exchange:消息交換機,它指定消息按什麼規則,路由到哪一個隊列。
Queue:消息隊列載體,每一個消息都會被投入到一個或多個隊列。
Binding:綁定,它的做用就是把exchange和queue按照路由規則綁定起來。
Routing Key:路由關鍵字,exchange根據這個關鍵字進行消息投遞。
vhost:虛擬主機,一個broker裏能夠開設多個vhost,用做不一樣用戶的權限分離。
producer:消息生產者,就是投遞消息的程序。
consumer:消息消費者,就是接受消息的程序。
channel:消息通道,在客戶端的每一個鏈接裏,可創建多個channel,每一個channel表明一個會話任務。
消息隊列的使用過程,以下:
(1)客戶端鏈接到消息隊列服務器,打開一個channel。
(2)客戶端聲明一個exchange,並設置相關屬性。
(3)客戶端聲明一個queue,並設置相關屬性。
(4)客戶端使用routing key,在exchange和queue之間創建好綁定關係。
(5)客戶端投遞消息到exchange。
exchange接收到消息後,就根據消息的key和已經設置的binding,進行消息路由,將消息投遞到一個或多個隊列裏。
號稱史上最快的消息隊列,它實際相似於Socket的一系列接口,他跟Socket的區別是:普通的socket是端到端的(1:1的關係),而ZMQ倒是能夠N:M 的關係,人們對BSD套接字的瞭解較多的是點對點的鏈接,點對點鏈接須要顯式地創建鏈接、銷燬鏈接、選擇協議(TCP/UDP)和處理錯誤等,而ZMQ屏蔽了這些細節,讓你的網絡編程更爲簡單。ZMQ用於node與node間的通訊,node能夠是主機或者是進程。
引用官方的說法: 「ZMQ(如下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層,像框架同樣的一個socket library,他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫,可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成爲標準網絡協議棧的一部分,以後進入Linux內核」。如今還未看到它們的成功。可是,它無疑是極具前景的、而且是人們更加須要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網絡應用程序極爲簡單和有趣。」
特色是:
高性能,非持久化
跨平臺:支持Linux、Windows、OS X等
多語言支持; C、C++、Java、.NET、Python等30多種開發語言
可單獨部署或集成到應用中使用
可做爲Socket通訊庫使用
與RabbitMQ相比,ZMQ並不像是一個傳統意義上的消息隊列服務器,事實上,它也根本不是一個服務器,更像一個底層的網絡通信庫,在Socket API之上作了一層封裝,將網絡通信、進程通信和線程通信抽象爲統一的API接口。支持「Request-Reply 「,」Publisher-Subscriber「,」Parallel Pipeline」三種基本模型和擴展模型。
ZeroMQ高性能設計要點:
一、無鎖的隊列模型
對於跨線程間的交互(用戶端和session)之間的數據交換通道pipe,採用無鎖的隊列算法CAS;在pipe兩端註冊有異步事件,在讀或者寫消息到pipe的時,會自動觸發讀寫事件。
二、批量處理的算法
對於傳統的消息處理,每一個消息在發送和接收的時候,都須要系統的調用,這樣對於大量的消息,系統的開銷比較大,zeroMQ對於批量的消息,進行了適應性的優化,能夠批量的接收和發送消息。
三、多核下的線程綁定,無須CPU切換
區別於傳統的多線程併發模式,信號量或者臨界區, zeroMQ充分利用多核的優點,每一個核綁定運行一個工做者線程,避免多線程之間的CPU切換開銷。
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統,它能夠處理消費者規模的網站中的全部動做流數據。 這種動做(網頁瀏覽,搜索和其餘用戶的行動)是在現代網絡上的許多社會功能的一個關鍵因素。 這些數據一般是因爲吞吐量的要求而經過處理日誌和日誌聚合來解決。 對於像Hadoop的同樣的日誌數據和離線分析系統,但又要求實時處理的限制,這是一個可行的解決方案。Kafka的目的是經過Hadoop的並行加載機制來統一線上和離線的消息處理,也是爲了經過集羣機來提供實時的消費。
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統,有以下特性:
經過O(1)的磁盤數據結構提供消息的持久化,這種結構對於即便數以TB的消息存儲也可以保持長時間的穩定性能。(文件追加的方式寫入數據,過時的數據按期刪除)
高吞吐量:即便是很是普通的硬件Kafka也能夠支持每秒數百萬的消息
支持經過Kafka服務器和消費機集羣來分區消息
支持Hadoop並行數據加載
Kafka相關概念
Kafka集羣包含一個或多個服務器,這種服務器被稱爲broker[5]
每條發佈到Kafka集羣的消息都有一個類別,這個類別被稱爲Topic。(物理上不一樣Topic的消息分開存儲,邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic便可生產或消費數據而沒必要關心數據存於何處)
Parition是物理上的概念,每一個Topic包含一個或多個Partition.
負責發佈消息到Kafka broker
消息消費者,向Kafka broker讀取消息的客戶端。
每一個Consumer屬於一個特定的Consumer Group(可爲每一個Consumer指定group name,若不指定group name則屬於默認的group)。
通常應用在大數據日誌處理或對實時性(少許延遲),可靠性(少許丟數據)要求稍低的場景使用。
RocketMQ是阿里開源的消息中間件,純Java開發,具備高吞吐量、高可用性、適合大規模分佈式系統應用的特色。RocketMQ思路起源於Kafka,但並非簡單的複製,它對消息的可靠傳輸及事務性作了優化,目前在阿里集團被普遍應用於交易、充值、流計算、消息推送、日誌流式處理、binglog分發等場景,支撐了阿里屢次雙十一活動。
由於是阿里內部從實踐到產品的產物,所以裏面不少接口、api並非很廣泛適用。可靠性毋庸置疑,並且與Kafka一脈相承(甚至更優),性能強勁,支持海量堆積。
Apache ActiveMQ 是一個很是流行、強大、開源的消息和集成模式(Integration Patterns)服務器,速度快、支持多種跨語言客戶端和協議,易於使用企業集成模式(Enterprise Integration Patterns),擁有許多先進的特性,徹底支持JMS 1.1和J2EE 1.4規範。ActiveMQ 基於Apache 2.0許可。
Apollo 以 ActiveMQ原型爲基礎,是一個更快、更可靠、更易於維護的消息代理工具。Apache 號稱 Apollo 爲最快、最強健的STOMP(Streaming Text Orientated Message Protocol,流文本定向消息協議)服務器。
Apollo的特性以下:
到底應該哪一個方案,仍是要看具體的需求。在咱們的設計中,MQ的功能與業務無關,所以優先考慮使用已有的中間件搭建。那麼具本選擇哪一個中間件呢?先來梳理下咱們對MQ的需求:
如前文所述,除了最基本生產消費模型,還須要MQ能支持REQUEST-REPLY模型,以提供對同步調用的支持。 此外,若是MQ能提供PUBLISH-SUBSCRIBE模型,則事件代理的實現能夠更加簡單。
考慮將來一到兩年內產品的發展,消息隊列的呑吐量預計不會超過 1W qps,但由單條消息延遲要求較高,但願儘可能的短。
由於是在線服務,所以須要較高的可用性,但充許有少許消息丟失。
包括學習成本、初期的開發部署成本、平常的運維成本等。
ActiveMQ與RabbitMQ在不少方面都很類似,但ActiveMQ對非JAVA生態的支持不及rabbitMQ, 加之精力有限,所以本文重點關注RabbitMQ。
特性
ActiveMQ
RabbitMQ
Kafka
RocketMQ
PRODUCER-COMSUMER
支持
支持
支持
支持
PUBLISH-SUBSCRIBE
支持
支持
支持
支持
REQUEST-REPLY
支持
支持
-
支持
API完備性
高
高
高
低(靜態配置)
多語言支持
支持,JAVA優先
語言無關
支持,JAVA優先
支持
單機呑吐量
萬級
萬級
十萬級
單機萬級
消息延遲
-
微秒級
毫秒級
-
可用性
高(主從)
高(主從)
很是高(分佈式)
高
消息丟失
-
低
理論上不會丟失
-
消息重複
-
可控制
理論上會有重複
-
文檔的完備性
高
高
高
中
提供快速入門
有
有
有
無
首次部署難度
-
低
中
高
注: - 表示還沒有查找到準確數據
消息隊列的選型須要根據具體應用需求而定,ZeroMQ小而美,RabbitMQ大而穩,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