訊息佇列得對比 常用訊息佇列介紹和對比
常用訊息佇列介紹和對比
訊息佇列是分散式應用間交換資訊的重要元件,訊息佇列可駐留在記憶體或磁碟上, 佇列可以儲存訊息直到它們被應用程式讀走。
通過訊息佇列,應用程式可以在不知道彼此位置的情況下獨立處理訊息,或者在處理訊息前不需要等待接收此訊息。
所以訊息佇列可以解決應用解耦、非同步訊息、流量削鋒等問題,是實現高效能、高可用、可伸縮和最終一致性架構中不可以或缺的一環。
現在比較常見的訊息佇列產品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。
1 ActiveMQ
ActiveMQ 是Apache出品,最流行的,能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
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的特性
⒋ 通過了常見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,進行測試
2 RabbitMQ
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,進行訊息路由,將訊息投遞到一個或多個佇列裡。
3 ZeroMQ
號稱史上最快的訊息佇列,它實際類似於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高效能設計要點:
1、無鎖的佇列模型
對於跨執行緒間的互動(使用者端和session)之間的資料交換通道pipe,採用無鎖的佇列演算法CAS;在pipe兩端註冊有非同步事件,在讀或者寫訊息到pipe的時,會自動觸發讀寫事件。
2、批量處理的演算法
對於傳統的訊息處理,每個訊息在傳送和接收的時候,都需要系統的呼叫,這樣對於大量的訊息,系統的開銷比較大,zeroMQ對於批量的訊息,進行了適應性的優化,可以批量的接收和傳送訊息。
3、多核下的執行緒繫結,無須CPU切換
區別於傳統的多執行緒併發模式,訊號量或者臨界區, zeroMQ充分利用多核的優勢,每個核繫結執行一個工作者執行緒,避免多執行緒之間的CPU切換開銷。
4 Kafka
Kafka是一種高吞吐量的分散式釋出訂閱訊息系統,它可以處理消費者規模的網站中的所有動作流資料。 這種動作(網頁瀏覽,搜尋和其他使用者的行動)是在現代網路上的許多社會功能的一個關鍵因素。 這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌資料和離線分析系統,但又要求實時處理的限制,這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理,也是為了通過叢集機來提供實時的消費。
Kafka是一種高吞吐量的分散式釋出訂閱訊息系統,有如下特性:
-
通過O(1)的磁碟資料結構提供訊息的持久化,這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。(檔案追加的方式寫入資料,過期的資料定期刪除)
-
高吞吐量:即使是非常普通的硬體Kafka也可以支援每秒數百萬的訊息
-
支援通過Kafka伺服器和消費機叢集來分割槽訊息
-
支援Hadoop並行資料載入
Kafka相關概念
- Broker
Kafka叢集包含一個或多個伺服器,這種伺服器被稱為broker[5]
- Topic
每條釋出到Kafka叢集的訊息都有一個類別,這個類別被稱為Topic。(物理上不同Topic的訊息分開儲存,邏輯上一個Topic的訊息雖然保存於一個或多個broker上但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處)
- Partition
Parition是物理上的概念,每個Topic包含一個或多個Partition.
- Producer
負責釋出訊息到Kafka broker
- Consumer
訊息消費者,向Kafka broker讀取訊息的客戶端。
- Consumer Group
每個Consumer屬於一個特定的Consumer Group(可為每個Consumer指定group name,若不指定group name則屬於預設的group)。
一般應用在大資料日誌處理或對實時性(少量延遲),可靠性(少量丟資料)要求稍低的場景使用。
5 RocketMQ
RocketMQ是阿里開源的訊息中介軟體,純Java開發,具有高吞吐量、高可用性、適合大規模分散式系統應用的特點。RocketMQ思路起源於Kafka,但並不是簡單的複製,它對訊息的可靠傳輸及事務性做了優化,目前在阿里集團被廣泛應用於交易、充值、流計算、訊息推送、日誌流式處理、binglog分發等場景,支撐了阿里多次雙十一活動。
因為是阿里內部從實踐到產品的產物,因此裡面很多介面、api並不是很普遍適用。可靠性毋庸置疑,而且與Kafka一脈相承(甚至更優),效能強勁,支援海量堆積。
選擇哪個中介軟體?
到底應該哪個方案,還是要看具體的需求。在我們的設計中,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優先 | 支援 |
單機呑吐量 | 萬級 | 萬級 | 十萬級 | 單機萬級 |
訊息延遲 | - | 微秒級 | 毫秒級 | - |
可用性 | 高(主從) | 高(主從) | 非常高(分散式) | 高 |
訊息丟失 | - | 低 | 理論上不會丟失 | - |
訊息重複 | - | 可控制 | 理論上會有重複 | - |
文件的完備性 | 高 | 高 | 高 | 中 |
提供快速入門 | 有 | 有 | 有 | 無 |
首次部署難度 | - | 低 | 中 | 高 |
訊息佇列是分散式應用間交換資訊的重要元件,訊息佇列可駐留在記憶體或磁碟上, 佇列可以儲存訊息直到它們被應用程式讀走。
通過訊息佇列,應用程式可以在不知道彼此位置的情況下獨立處理訊息,或者在處理訊息前不需要等待接收此訊息。
所以訊息佇列可以解決應用解耦、非同步訊息、流量削鋒等問題,是實現高效能、高可用、可伸縮和最終一致性架構中不可以或缺的一環。
現在比較常見的訊息佇列產品主要有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、RocketMQ等。
1 ActiveMQ
ActiveMQ 是Apache出品,最流行的,能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現,儘管JMS規範出臺已經是很久的事情了,但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
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的特性
⒋ 通過了常見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,進行測試
2 RabbitMQ
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,進行訊息路由,將訊息投遞到一個或多個佇列裡。
3 ZeroMQ
號稱史上最快的訊息佇列,它實際類似於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高效能設計要點:
1、無鎖的佇列模型
對於跨執行緒間的互動(使用者端和session)之間的資料交換通道pipe,採用無鎖的佇列演算法CAS;在pipe兩端註冊有非同步事件,在讀或者寫訊息到pipe的時,會自動觸發讀寫事件。
2、批量處理的演算法
對於傳統的訊息處理,每個訊息在傳送和接收的時候,都需要系統的呼叫,這樣對於大量的訊息,系統的開銷比較大,zeroMQ對於批量的訊息,進行了適應性的優化,可以批量的接收和傳送訊息。
3、多核下的執行緒繫結,無須CPU切換
區別於傳統的多執行緒併發模式,訊號量或者臨界區, zeroMQ充分利用多核的優勢,每個核繫結執行一個工作者執行緒,避免多執行緒之間的CPU切換開銷。
4 Kafka
Kafka是一種高吞吐量的分散式釋出訂閱訊息系統,它可以處理消費者規模的網站中的所有動作流資料。 這種動作(網頁瀏覽,搜尋和其他使用者的行動)是在現代網路上的許多社會功能的一個關鍵因素。 這些資料通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌資料和離線分析系統,但又要求實時處理的限制,這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理,也是為了通過叢集機來提供實時的消費。
Kafka是一種高吞吐量的分散式釋出訂閱訊息系統,有如下特性:
-
通過O(1)的磁碟資料結構提供訊息的持久化,這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。(檔案追加的方式寫入資料,過期的資料定期刪除)
-
高吞吐量:即使是非常普通的硬體Kafka也可以支援每秒數百萬的訊息
-
支援通過Kafka伺服器和消費機叢集來分割槽訊息
-
支援Hadoop並行資料載入
Kafka相關概念
- Broker
Kafka叢集包含一個或多個伺服器,這種伺服器被稱為broker[5]
- Topic
每條釋出到Kafka叢集的訊息都有一個類別,這個類別被稱為Topic。(物理上不同Topic的訊息分開儲存,邏輯上一個Topic的訊息雖然保存於一個或多個broker上但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處)
- Partition
Parition是物理上的概念,每個Topic包含一個或多個Partition.
- Producer
負責釋出訊息到Kafka broker
- Consumer
訊息消費者,向Kafka broker讀取訊息的客戶端。
- Consumer Group
每個Consumer屬於一個特定的Consumer Group(可為每個Consumer指定group name,若不指定group name則屬於預設的group)。
一般應用在大資料日誌處理或對實時性(少量延遲),可靠性(少量丟資料)要求稍低的場景使用。
5 RocketMQ
RocketMQ是阿里開源的訊息中介軟體,純Java開發,具有高吞吐量、高可用性、適合大規模分散式系統應用的特點。RocketMQ思路起源於Kafka,但並不是簡單的複製,它對訊息的可靠傳輸及事務性做了優化,目前在阿里集團被廣泛應用於交易、充值、流計算、訊息推送、日誌流式處理、binglog分發等場景,支撐了阿里多次雙十一活動。
因為是阿里內部從實踐到產品的產物,因此裡面很多介面、api並不是很普遍適用。可靠性毋庸置疑,而且與Kafka一脈相承(甚至更優),效能強勁,支援海量堆積。
選擇哪個中介軟體?
到底應該哪個方案,還是要看具體的需求。在我們的設計中,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優先 | 支援 |
單機呑吐量 | 萬級 | 萬級 | 十萬級 | 單機萬級 |
訊息延遲 | - | 微秒級 | 毫秒級 | - |
可用性 | 高(主從) | 高(主從) | 非常高(分散式) | 高 |
訊息丟失 | - | 低 | 理論上不會丟失 | - |
訊息重複 | - | 可控制 | 理論上會有重複 | - |
文件的完備性 | 高 | 高 | 高 | 中 |
提供快速入門 | 有 | 有 | 有 | 無 |
首次部署難度 | - | 低 | 中 | 高 |