對(duì)比Kafka、RabbitMQ、RocketMQ、ActiveMQ四個(gè)分布式消息隊(duì)列有哪些區(qū)別

這篇文章主要介紹對(duì)比Kafka、RabbitMQ、RocketMQ、ActiveMQ四個(gè)分布式消息隊(duì)列有哪些區(qū)別，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

一、資料文檔

Kafka：中。有kafka作者自己寫(xiě)的書(shū)，網(wǎng)上資料也有一些。 rabbitmq：多。有一些不錯(cuò)的書(shū)，網(wǎng)上資料多。  zeromq：少。沒(méi)有專門(mén)寫(xiě)zeromq的書(shū)，網(wǎng)上的資料多是一些代碼的實(shí)現(xiàn)和簡(jiǎn)單介紹。  rocketmq：少。沒(méi)有專門(mén)寫(xiě)rocketmq的書(shū)，網(wǎng)上的資料良莠不齊，官方文檔很簡(jiǎn)潔，但是對(duì)技術(shù)細(xì)節(jié)沒(méi)有過(guò)多的描述。  activemq：多。沒(méi)有專門(mén)寫(xiě)activemq的書(shū)，網(wǎng)上資料多。

二、開(kāi)發(fā)語(yǔ)言

Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java

三、支持的協(xié)議

Kafka：自己定義的一套…(基于TCP) rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己定義的一套…  activemq：OpenWire、STOMP、REST、XMPP、AMQP

四、消息存儲(chǔ)

Kafka：內(nèi)存、磁盤(pán)、數(shù)據(jù)庫(kù)。支持大量堆積。

kafka的最小存儲(chǔ)單元是分區(qū)，一個(gè)topic包含多個(gè)分區(qū)，kafka創(chuàng)建主題時(shí)，這些分區(qū)會(huì)被分配在多個(gè)服務(wù)器上，通常一個(gè)broker一臺(tái)服務(wù)器。  分區(qū)首領(lǐng)會(huì)均勻地分布在不同的服務(wù)器上，分區(qū)副本也會(huì)均勻的分布在不同的服務(wù)器上，確保負(fù)載均衡和高可用性，當(dāng)新的broker加入集群的時(shí)候，部分副本會(huì)被移動(dòng)到新的broker上。  根據(jù)配置文件中的目錄清單，kafka會(huì)把新的分區(qū)分配給目錄清單里分區(qū)數(shù)最少的目錄。  默認(rèn)情況下，分區(qū)器使用輪詢算法把消息均衡地分布在同一個(gè)主題的不同分區(qū)中，對(duì)于發(fā)送時(shí)指定了key的情況，會(huì)根據(jù)key的hashcode取模后的值存到對(duì)應(yīng)的分區(qū)中。

rabbitmq：內(nèi)存、磁盤(pán)。支持少量堆積。

rabbitmq的消息分為持久化的消息和非持久化消息，不管是持久化的消息還是非持久化的消息都可以寫(xiě)入到磁盤(pán)。  持久化的消息在到達(dá)隊(duì)列時(shí)就寫(xiě)入到磁盤(pán)，并且如果可以，持久化的消息也會(huì)在內(nèi)存中保存一份備份，這樣可以提高一定的性能，當(dāng)內(nèi)存吃緊的時(shí)候會(huì)從內(nèi)存中清除。非持久化的消息一般只存在于內(nèi)存中，在內(nèi)存吃緊的時(shí)候會(huì)被換入到磁盤(pán)中，以節(jié)省內(nèi)存。

引入鏡像隊(duì)列機(jī)制，可將重要隊(duì)列“復(fù)制”到集群中的其他broker上，保證這些隊(duì)列的消息不會(huì)丟失。配置鏡像的隊(duì)列，都包含一個(gè)主節(jié)點(diǎn)master和多個(gè)從節(jié)點(diǎn)slave,如果master失效，加入時(shí)間最長(zhǎng)的slave會(huì)被提升為新的master，除發(fā)送消息外的所有動(dòng)作都向master發(fā)送，然后由master將命令執(zhí)行結(jié)果廣播給各個(gè)slave，rabbitmq會(huì)讓master均勻地分布在不同的服務(wù)器上，而同一個(gè)隊(duì)列的slave也會(huì)均勻地分布在不同的服務(wù)器上，保證負(fù)載均衡和高可用性。

zeromq：消息發(fā)送端的內(nèi)存或者磁盤(pán)中。不支持持久化。

rocketmq：磁盤(pán)。支持大量堆積。

commitLog文件存放實(shí)際的消息數(shù)據(jù)，每個(gè)commitLog上限是1G，滿了之后會(huì)自動(dòng)新建一個(gè)commitLog文件保存數(shù)據(jù)。ConsumeQueue隊(duì)列只存放offset、size、tagcode，非常小，分布在多個(gè)broker上。ConsumeQueue相當(dāng)于CommitLog的索引文件，消費(fèi)者消費(fèi)時(shí)會(huì)從consumeQueue中查找消息在commitLog中的offset，再去commitLog中查找元數(shù)據(jù)。

ConsumeQueue存儲(chǔ)格式的特性，保證了寫(xiě)過(guò)程的順序?qū)懕P(pán)(寫(xiě)CommitLog文件)，大量數(shù)據(jù)IO都在順序?qū)懲粋€(gè)commitLog，滿1G了再寫(xiě)新的。加上rocketmq是累計(jì)4K才強(qiáng)制從PageCache中刷到磁盤(pán)(緩存)，所以高并發(fā)寫(xiě)性能突出。

activemq：內(nèi)存、磁盤(pán)、數(shù)據(jù)庫(kù)。支持少量堆積。

五、消息事務(wù)

Kafka：支持 rabbitmq：支持。  客戶端將信道設(shè)置為事務(wù)模式，只有當(dāng)消息被rabbitMq接收，事務(wù)才能提交成功，否則在捕獲異常后進(jìn)行回滾。使用事務(wù)會(huì)使得性能有所下降 zeromq：不支持  rocketmq：支持 activemq：支持

六、負(fù)載均衡

Kafka：支持負(fù)載均衡。

1>一個(gè)broker通常就是一臺(tái)服務(wù)器節(jié)點(diǎn)。對(duì)于同一個(gè)Topic的不同分區(qū)，Kafka會(huì)盡力將這些分區(qū)分布到不同的Broker服務(wù)器上，zookeeper保存了broker、主題和分區(qū)的元數(shù)據(jù)信息。分區(qū)首領(lǐng)會(huì)處理來(lái)自客戶端的生產(chǎn)請(qǐng)求，kafka分區(qū)首領(lǐng)會(huì)被分配到不同的broker服務(wù)器上，讓不同的broker服務(wù)器共同分擔(dān)任務(wù)。

每一個(gè)broker都緩存了元數(shù)據(jù)信息，客戶端可以從任意一個(gè)broker獲取元數(shù)據(jù)信息并緩存起來(lái)，根據(jù)元數(shù)據(jù)信息知道要往哪里發(fā)送請(qǐng)求。

2>kafka的消費(fèi)者組訂閱同一個(gè)topic，會(huì)盡可能地使得每一個(gè)消費(fèi)者分配到相同數(shù)量的分區(qū)，分?jǐn)傌?fù)載。

3>當(dāng)消費(fèi)者加入或者退出消費(fèi)者組的時(shí)候，還會(huì)觸發(fā)再均衡，為每一個(gè)消費(fèi)者重新分配分區(qū)，分?jǐn)傌?fù)載。

kafka的負(fù)載均衡大部分是自動(dòng)完成的，分區(qū)的創(chuàng)建也是kafka完成的，隱藏了很多細(xì)節(jié)，避免了繁瑣的配置和人為疏忽造成的負(fù)載問(wèn)題。

4>發(fā)送端由topic和key來(lái)決定消息發(fā)往哪個(gè)分區(qū)，如果key為null，那么會(huì)使用輪詢算法將消息均衡地發(fā)送到同一個(gè)topic的不同分區(qū)中。如果key不為null，那么會(huì)根據(jù)key的hashcode取模計(jì)算出要發(fā)往的分區(qū)。

rabbitmq：對(duì)負(fù)載均衡的支持不好。

1>消息被投遞到哪個(gè)隊(duì)列是由交換器和key決定的，交換器、路由鍵、隊(duì)列都需要手動(dòng)創(chuàng)建。

rabbitmq客戶端發(fā)送消息要和broker建立連接，需要事先知道broker上有哪些交換器，有哪些隊(duì)列。通常要聲明要發(fā)送的目標(biāo)隊(duì)列，如果沒(méi)有目標(biāo)隊(duì)列，會(huì)在broker上創(chuàng)建一個(gè)隊(duì)列，如果有，就什么都不處理，接著往這個(gè)隊(duì)列發(fā)送消息。假設(shè)大部分繁重任務(wù)的隊(duì)列都創(chuàng)建在同一個(gè)broker上，那么這個(gè)broker的負(fù)載就會(huì)過(guò)大。(可以在上線前預(yù)先創(chuàng)建隊(duì)列，無(wú)需聲明要發(fā)送的隊(duì)列，但是發(fā)送時(shí)不會(huì)嘗試創(chuàng)建隊(duì)列，可能出現(xiàn)找不到隊(duì)列的問(wèn)題，rabbitmq的備份交換器會(huì)把找不到隊(duì)列的消息保存到一個(gè)專門(mén)的隊(duì)列中，以便以后查詢使用)

使用鏡像隊(duì)列機(jī)制建立rabbitmq集群可以解決這個(gè)問(wèn)題，形成master-slave的架構(gòu)，master節(jié)點(diǎn)會(huì)均勻分布在不同的服務(wù)器上，讓每一臺(tái)服務(wù)器分?jǐn)傌?fù)載。slave節(jié)點(diǎn)只是負(fù)責(zé)轉(zhuǎn)發(fā)，在master失效時(shí)會(huì)選擇加入時(shí)間最長(zhǎng)的slave成為master。

當(dāng)新節(jié)點(diǎn)加入鏡像隊(duì)列的時(shí)候，隊(duì)列中的消息不會(huì)同步到新的slave中，除非調(diào)用同步命令，但是調(diào)用命令后，隊(duì)列會(huì)阻塞，不能在生產(chǎn)環(huán)境中調(diào)用同步命令。

2>當(dāng)rabbitmq隊(duì)列擁有多個(gè)消費(fèi)者的時(shí)候，隊(duì)列收到的消息將以輪詢的分發(fā)方式發(fā)送給消費(fèi)者。每條消息只會(huì)發(fā)送給訂閱列表里的一個(gè)消費(fèi)者，不會(huì)重復(fù)。

這種方式非常適合擴(kuò)展，而且是專門(mén)為并發(fā)程序設(shè)計(jì)的。

如果某些消費(fèi)者的任務(wù)比較繁重，那么可以設(shè)置basicQos限制信道上消費(fèi)者能保持的***未確認(rèn)消息的數(shù)量，在達(dá)到上限時(shí)，rabbitmq不再向這個(gè)消費(fèi)者發(fā)送任何消息。

3>對(duì)于rabbitmq而言，客戶端與集群建立的TCP連接不是與集群中所有的節(jié)點(diǎn)建立連接，而是挑選其中一個(gè)節(jié)點(diǎn)建立連接。

但是rabbitmq集群可以借助HAProxy、LVS技術(shù)，或者在客戶端使用算法實(shí)現(xiàn)負(fù)載均衡，引入負(fù)載均衡之后，各個(gè)客戶端的連接可以分?jǐn)偟郊旱母鱾€(gè)節(jié)點(diǎn)之中。

客戶端均衡算法：

1)輪詢法。按順序返回下一個(gè)服務(wù)器的連接地址。

2)加權(quán)輪詢法。給配置高、負(fù)載低的機(jī)器配置更高的權(quán)重，讓其處理更多的請(qǐng)求;而配置低、負(fù)載高的機(jī)器，給其分配較低的權(quán)重，降低其系統(tǒng)負(fù)載。

3)隨機(jī)法。隨機(jī)選取一個(gè)服務(wù)器的連接地址。

4)加權(quán)隨機(jī)法。按照概率隨機(jī)選取連接地址。

5)源地址哈希法。通過(guò)哈希函數(shù)計(jì)算得到的一個(gè)數(shù)值，用該數(shù)值對(duì)服務(wù)器列表的大小進(jìn)行取模運(yùn)算。

6)最小連接數(shù)法。動(dòng)態(tài)選擇當(dāng)前連接數(shù)最少的一臺(tái)服務(wù)器的連接地址。

zeromq：去中心化，不支持負(fù)載均衡。本身只是一個(gè)多線程網(wǎng)絡(luò)庫(kù)。

rocketmq：支持負(fù)載均衡。

一個(gè)broker通常是一個(gè)服務(wù)器節(jié)點(diǎn)，broker分為master和slave,master和slave存儲(chǔ)的數(shù)據(jù)一樣，slave從master同步數(shù)據(jù)。

1>nameserver與每個(gè)集群成員保持心跳，保存著Topic-Broker路由信息，同一個(gè)topic的隊(duì)列會(huì)分布在不同的服務(wù)器上。

2>發(fā)送消息通過(guò)輪詢隊(duì)列的方式發(fā)送，每個(gè)隊(duì)列接收平均的消息量。發(fā)送消息指定topic、tags、keys，無(wú)法指定投遞到哪個(gè)隊(duì)列(沒(méi)有意義，集群消費(fèi)和廣播消費(fèi)跟消息存放在哪個(gè)隊(duì)列沒(méi)有關(guān)系)。

tags選填，類(lèi)似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過(guò)濾使用。目前只支 持每個(gè)消息設(shè)置一個(gè) tag，所以也可以類(lèi)比為 Notify 的  MessageType 概念。

keys選填，代表這條消息的業(yè)務(wù)關(guān)鍵詞，服務(wù)器會(huì)根據(jù) keys 創(chuàng)建哈希索引，設(shè)置后， 可以在 Console 系統(tǒng)根據(jù) Topic、Keys  來(lái)查詢消息，由于是哈希索引，請(qǐng)盡可能 保證 key 唯一，例如訂單號(hào)，商品 Id 等。

3>rocketmq的負(fù)載均衡策略規(guī)定：Consumer數(shù)量應(yīng)該小于等于Queue數(shù)量，如果Consumer超過(guò)Queue數(shù)量，那么多余的Consumer  將不能消費(fèi)消息。這一點(diǎn)和kafka是一致的，rocketmq會(huì)盡可能地為每一個(gè)Consumer分配相同數(shù)量的隊(duì)列，分?jǐn)傌?fù)載。

activemq：支持負(fù)載均衡。可以基于zookeeper實(shí)現(xiàn)負(fù)載均衡。

七、集群方式

Kafka：天然的‘Leader-Slave’無(wú)狀態(tài)集群，每臺(tái)服務(wù)器既是Master也是Slave。

分區(qū)首領(lǐng)均勻地分布在不同的kafka服務(wù)器上，分區(qū)副本也均勻地分布在不同的kafka服務(wù)器上，所以每一臺(tái)kafka服務(wù)器既含有分區(qū)首領(lǐng)，同時(shí)又含有分區(qū)副本，每一臺(tái)kafka服務(wù)器是某一臺(tái)kafka服務(wù)器的Slave，同時(shí)也是某一臺(tái)kafka服務(wù)器的leader。

kafka的集群依賴于zookeeper，zookeeper支持熱擴(kuò)展，所有的broker、消費(fèi)者、分區(qū)都可以動(dòng)態(tài)加入移除，而無(wú)需關(guān)閉服務(wù)，與不依靠zookeeper集群的mq相比，這是***的優(yōu)勢(shì)。

rabbitmq：支持簡(jiǎn)單集群，'復(fù)制'模式，對(duì)高級(jí)集群模式支持不好。

rabbitmq的每一個(gè)節(jié)點(diǎn)，不管是單一節(jié)點(diǎn)系統(tǒng)或者是集群中的一部分，要么是內(nèi)存節(jié)點(diǎn)，要么是磁盤(pán)節(jié)點(diǎn)，集群中至少要有一個(gè)是磁盤(pán)節(jié)點(diǎn)。

在rabbitmq集群中創(chuàng)建隊(duì)列，集群只會(huì)在單個(gè)節(jié)點(diǎn)創(chuàng)建隊(duì)列進(jìn)程和完整的隊(duì)列信息(元數(shù)據(jù)、狀態(tài)、內(nèi)容)，而不是在所有節(jié)點(diǎn)上創(chuàng)建。

引入鏡像隊(duì)列，可以避免單點(diǎn)故障，確保服務(wù)的可用性，但是需要人為地為某些重要的隊(duì)列配置鏡像。

zeromq：去中心化，不支持集群。

rocketmq：常用 多對(duì)'Master-Slave' 模式，開(kāi)源版本需手動(dòng)切換Slave變成Master

Name Server是一個(gè)幾乎無(wú)狀態(tài)節(jié)點(diǎn)，可集群部署，節(jié)點(diǎn)之間無(wú)任何信息同步。

Broker部署相對(duì)復(fù)雜，Broker分為Master與Slave，一個(gè)Master可以對(duì)應(yīng)多個(gè)Slave，但是一個(gè)Slave只能對(duì)應(yīng)一個(gè)Master，Master與Slave的對(duì)應(yīng)關(guān)系通過(guò)指定相同的BrokerName，不同的BrokerId來(lái)定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個(gè)。每個(gè)Broker與Name  Server集群中的所有節(jié)點(diǎn)建立長(zhǎng)連接，定時(shí)注冊(cè)Topic信息到所有Name Server。

Producer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長(zhǎng)連接，定期從Name  Server取Topic路由信息，并向提供Topic服務(wù)的Master建立長(zhǎng)連接，且定時(shí)向Master發(fā)送心跳。Producer完全無(wú)狀態(tài)，可集群部署。

Consumer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長(zhǎng)連接，定期從Name  Server取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長(zhǎng)連接，且定時(shí)向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。

客戶端先找到NameServer, 然后通過(guò)NameServer再找到 Broker。

一個(gè)topic有多個(gè)隊(duì)列，這些隊(duì)列會(huì)均勻地分布在不同的broker服務(wù)器上。rocketmq隊(duì)列的概念和kafka的分區(qū)概念是基本一致的，kafka同一個(gè)topic的分區(qū)盡可能地分布在不同的broker上，分區(qū)副本也會(huì)分布在不同的broker上。

rocketmq集群的slave會(huì)從master拉取數(shù)據(jù)備份，master分布在不同的broker上。

activemq：支持簡(jiǎn)單集群模式，比如'主-備'，對(duì)高級(jí)集群模式支持不好。

八、管理界面

Kafka：一般 rabbitmq：好 zeromq：無(wú) rocketmq：無(wú) activemq：一般

九、可用性

Kafka：非常高(分布式) rabbitmq：高(主從) zeromq：高。 rocketmq：非常高(分布式) activemq：高(主從)

十、消息重復(fù)

Kafka：支持at least once、at most once

rabbitmq：支持at least once、at most once

zeromq：只有重傳機(jī)制，但是沒(méi)有持久化，消息丟了重傳也沒(méi)有用。既不是at least once、也不是at most once、更不是exactly  only once

rocketmq：支持at least once

activemq：支持at least once

十一、吞吐量TPS

Kafka：極大 Kafka按批次發(fā)送消息和消費(fèi)消息。發(fā)送端將多個(gè)小消息合并，批量發(fā)向Broker，消費(fèi)端每次取出一個(gè)批次的消息批量處理。  rabbitmq：比較大 zeromq：極大 rocketmq：大 rocketMQ接收端可以批量消費(fèi)消息，可以配置每次消費(fèi)的消息數(shù)，但是發(fā)送端不是批量發(fā)送。  activemq：比較大

十二、訂閱形式和消息分發(fā)

Kafka：基于topic以及按照topic進(jìn)行正則匹配的發(fā)布訂閱模式。

【發(fā)送】

發(fā)送端由topic和key來(lái)決定消息發(fā)往哪個(gè)分區(qū)，如果key為null，那么會(huì)使用輪詢算法將消息均衡地發(fā)送到同一個(gè)topic的不同分區(qū)中。如果key不為null，那么會(huì)根據(jù)key的hashcode取模計(jì)算出要發(fā)往的分區(qū)。

【接收】

1>consumer向群組協(xié)調(diào)器broker發(fā)送心跳來(lái)維持他們和群組的從屬關(guān)系以及他們對(duì)分區(qū)的所有權(quán)關(guān)系，所有權(quán)關(guān)系一旦被分配就不會(huì)改變除非發(fā)生再均衡(比如有一個(gè)consumer加入或者離開(kāi)consumer  group)，consumer只會(huì)從對(duì)應(yīng)的分區(qū)讀取消息。

2>kafka限制consumer個(gè)數(shù)要少于分區(qū)個(gè)數(shù),每個(gè)消息只會(huì)被同一個(gè) Consumer  Group的一個(gè)consumer消費(fèi)(非廣播)。

3>kafka的 Consumer Group訂閱同一個(gè)topic，會(huì)盡可能地使得每一個(gè)consumer分配到相同數(shù)量的分區(qū)，不同 Consumer  Group訂閱同一個(gè)主題相互獨(dú)立，同一個(gè)消息會(huì)被不同的 Consumer Group處理。

rabbitmq：提供了4種：direct, topic ,Headers和fanout。

【發(fā)送】

先要聲明一個(gè)隊(duì)列，這個(gè)隊(duì)列會(huì)被創(chuàng)建或者已經(jīng)被創(chuàng)建，隊(duì)列是基本存儲(chǔ)單元。

由exchange和key決定消息存儲(chǔ)在哪個(gè)隊(duì)列。

direct>發(fā)送到和bindingKey完全匹配的隊(duì)列。

topic>路由key是含有"."的字符串，會(huì)發(fā)送到含有“*”、“#”進(jìn)行模糊匹配的bingKey對(duì)應(yīng)的隊(duì)列。

fanout>與key無(wú)關(guān)，會(huì)發(fā)送到所有和exchange綁定的隊(duì)列

headers>與key無(wú)關(guān)，消息內(nèi)容的headers屬性(一個(gè)鍵值對(duì))和綁定鍵值對(duì)完全匹配時(shí)，會(huì)發(fā)送到此隊(duì)列。此方式性能低一般不用

【接收】

rabbitmq的隊(duì)列是基本存儲(chǔ)單元，不再被分區(qū)或者分片，對(duì)于我們已經(jīng)創(chuàng)建了的隊(duì)列，消費(fèi)端要指定從哪一個(gè)隊(duì)列接收消息。

當(dāng)rabbitmq隊(duì)列擁有多個(gè)消費(fèi)者的時(shí)候，隊(duì)列收到的消息將以輪詢的分發(fā)方式發(fā)送給消費(fèi)者。每條消息只會(huì)發(fā)送給訂閱列表里的一個(gè)消費(fèi)者，不會(huì)重復(fù)。

這種方式非常適合擴(kuò)展，而且是專門(mén)為并發(fā)程序設(shè)計(jì)的。

如果某些消費(fèi)者的任務(wù)比較繁重，那么可以設(shè)置basicQos限制信道上消費(fèi)者能保持的***未確認(rèn)消息的數(shù)量，在達(dá)到上限時(shí)，rabbitmq不再向這個(gè)消費(fèi)者發(fā)送任何消息。

zeromq：點(diǎn)對(duì)點(diǎn)(p2p)

rocketmq：基于topic/messageTag以及按照消息類(lèi)型、屬性進(jìn)行正則匹配的發(fā)布訂閱模式

【發(fā)送】

發(fā)送消息通過(guò)輪詢隊(duì)列的方式發(fā)送，每個(gè)隊(duì)列接收平均的消息量。發(fā)送消息指定topic、tags、keys，無(wú)法指定投遞到哪個(gè)隊(duì)列(沒(méi)有意義，集群消費(fèi)和廣播消費(fèi)跟消息存放在哪個(gè)隊(duì)列沒(méi)有關(guān)系)。

tags選填，類(lèi)似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過(guò)濾使用。目前只支 持每個(gè)消息設(shè)置一個(gè) tag，所以也可以類(lèi)比為 Notify 的  MessageType 概念。

keys選填，代表這條消息的業(yè)務(wù)關(guān)鍵詞，服務(wù)器會(huì)根據(jù) keys 創(chuàng)建哈希索引，設(shè)置后， 可以在 Console 系統(tǒng)根據(jù) Topic、Keys  來(lái)查詢消息，由于是哈希索引，請(qǐng)盡可能 保證 key 唯一，例如訂單號(hào)，商品 Id 等。

【接收】

1>廣播消費(fèi)。一條消息被多個(gè)Consumer消費(fèi)，即使Consumer屬于同一個(gè)ConsumerGroup，消息也會(huì)被ConsumerGroup中的每個(gè)Consumer都消費(fèi)一次。

2>集群消費(fèi)。一個(gè) Consumer Group中的Consumer實(shí)例平均分?jǐn)傁M(fèi)消息。例如某個(gè)Topic有 9 條消息，其中一個(gè)Consumer  Group有3個(gè)實(shí)例，那么每個(gè)實(shí)例只消費(fèi)其中的 3 條消息。即每一個(gè)隊(duì)列都把消息輪流分發(fā)給每個(gè)consumer。

activemq：點(diǎn)對(duì)點(diǎn)(p2p)、廣播(發(fā)布-訂閱)

點(diǎn)對(duì)點(diǎn)模式，每個(gè)消息只有1個(gè)消費(fèi)者;

發(fā)布/訂閱模式，每個(gè)消息可以有多個(gè)消費(fèi)者。

【發(fā)送】

點(diǎn)對(duì)點(diǎn)模式：先要指定一個(gè)隊(duì)列，這個(gè)隊(duì)列會(huì)被創(chuàng)建或者已經(jīng)被創(chuàng)建。

發(fā)布/訂閱模式：先要指定一個(gè)topic，這個(gè)topic會(huì)被創(chuàng)建或者已經(jīng)被創(chuàng)建。

【接收】

點(diǎn)對(duì)點(diǎn)模式：對(duì)于已經(jīng)創(chuàng)建了的隊(duì)列，消費(fèi)端要指定從哪一個(gè)隊(duì)列接收消息。

發(fā)布/訂閱模式：對(duì)于已經(jīng)創(chuàng)建了的topic，消費(fèi)端要指定訂閱哪一個(gè)topic的消息。

十三、順序消息

Kafka：支持。

設(shè)置生產(chǎn)者的max.in.flight.requests.per.connection為1，可以保證消息是按照發(fā)送順序?qū)懭敕?wù)器的，即使發(fā)生了重試。

kafka保證同一個(gè)分區(qū)里的消息是有序的，但是這種有序分兩種情況

1>key為null，消息逐個(gè)被寫(xiě)入不同主機(jī)的分區(qū)中，但是對(duì)于每個(gè)分區(qū)依然是有序的

2>key不為null , 消息被寫(xiě)入到同一個(gè)分區(qū)，這個(gè)分區(qū)的消息都是有序。

rabbitmq：不支持

zeromq：不支持

rocketmq：支持

activemq：不支持

十四、消息確認(rèn)

Kafka：支持。

1>發(fā)送方確認(rèn)機(jī)制

ack=0，不管消息是否成功寫(xiě)入分區(qū)

ack=1，消息成功寫(xiě)入首領(lǐng)分區(qū)后，返回成功

ack=all，消息成功寫(xiě)入所有分區(qū)后，返回成功。

2>接收方確認(rèn)機(jī)制

自動(dòng)或者手動(dòng)提交分區(qū)偏移量，早期版本的kafka偏移量是提交給Zookeeper的，這樣使得zookeeper的壓力比較大，更新版本的kafka的偏移量是提交給kafka服務(wù)器的，不再依賴于zookeeper群組，集群的性能更加穩(wěn)定。

rabbitmq：支持。

1>發(fā)送方確認(rèn)機(jī)制，消息被投遞到所有匹配的隊(duì)列后，返回成功。如果消息和隊(duì)列是可持久化的，那么在寫(xiě)入磁盤(pán)后，返回成功。支持批量確認(rèn)和異步確認(rèn)。

2>接收方確認(rèn)機(jī)制，設(shè)置autoAck為false，需要顯式確認(rèn)，設(shè)置autoAck為true，自動(dòng)確認(rèn)。

當(dāng)autoAck為false的時(shí)候，rabbitmq隊(duì)列會(huì)分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經(jīng)投遞但是沒(méi)收到確認(rèn)的消息。如果一直沒(méi)有收到確認(rèn)信號(hào)，并且consumer已經(jīng)斷開(kāi)連接，rabbitmq會(huì)安排這個(gè)消息重新進(jìn)入隊(duì)列，投遞給原來(lái)的消費(fèi)者或者下一個(gè)消費(fèi)者。

未確認(rèn)的消息不會(huì)有過(guò)期時(shí)間，如果一直沒(méi)有確認(rèn)，并且沒(méi)有斷開(kāi)連接，rabbitmq會(huì)一直等待，rabbitmq允許一條消息處理的時(shí)間可以很久很久。

zeromq：支持。

rocketmq：支持。

activemq：支持。

十五、消息回溯

Kafka：支持指定分區(qū)offset位置的回溯。 rabbitmq：不支持 zeromq：不支持 rocketmq：支持指定時(shí)間點(diǎn)的回溯。  activemq：不支持

十六、消息重試

Kafka：不支持，但是可以實(shí)現(xiàn)。

kafka支持指定分區(qū)offset位置的回溯，可以實(shí)現(xiàn)消息重試。

rabbitmq：不支持，但是可以利用消息確認(rèn)機(jī)制實(shí)現(xiàn)。

rabbitmq接收方確認(rèn)機(jī)制，設(shè)置autoAck為false。

當(dāng)autoAck為false的時(shí)候，rabbitmq隊(duì)列會(huì)分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經(jīng)投遞但是沒(méi)收到確認(rèn)的消息。如果一直沒(méi)有收到確認(rèn)信號(hào)，并且consumer已經(jīng)斷開(kāi)連接，rabbitmq會(huì)安排這個(gè)消息重新進(jìn)入隊(duì)列，投遞給原來(lái)的消費(fèi)者或者下一個(gè)消費(fèi)者。

zeromq：不支持，

rocketmq：支持。

消息消費(fèi)失敗的大部分場(chǎng)景下，立即重試99%都會(huì)失敗，所以rocketmq的策略是在消費(fèi)失敗時(shí)定時(shí)重試，每次時(shí)間間隔相同。

1>發(fā)送端的 send 方法本身支持內(nèi)部重試，重試邏輯如下：

a)至多重試3次;

b)如果發(fā)送失敗，則輪轉(zhuǎn)到下一個(gè)broker;

c)這個(gè)方法的總耗時(shí)不超過(guò)sendMsgTimeout 設(shè)置的值，默認(rèn) 10s，超過(guò)時(shí)間不在重試。

2>接收端。

Consumer 消費(fèi)消息失敗后，要提供一種重試機(jī)制，令消息再消費(fèi)一次。Consumer 消費(fèi)消息失敗通常可以分為以下兩種情況：

由于消息本身的原因，例如反序列化失敗，消息數(shù)據(jù)本身無(wú)法處理(例如話費(fèi)充值，當(dāng)前消息的手機(jī)號(hào)被

注銷(xiāo)，無(wú)法充值)等。定時(shí)重試機(jī)制，比如過(guò) 10s 秒后再重試。

由于依賴的下游應(yīng)用服務(wù)不可用，例如 db 連接不可用，外系統(tǒng)網(wǎng)絡(luò)不可達(dá)等。

即使跳過(guò)當(dāng)前失敗的消息，消費(fèi)其他消息同樣也會(huì)報(bào)錯(cuò)。這種情況可以 sleep 30s，再消費(fèi)下一條消息，減輕 Broker 重試消息的壓力。

activemq：不支持

十七、并發(fā)度

Kafka：高

一個(gè)線程一個(gè)消費(fèi)者，kafka限制消費(fèi)者的個(gè)數(shù)要小于等于分區(qū)數(shù)，如果要提高并行度，可以在消費(fèi)者中再開(kāi)啟多線程，或者增加consumer實(shí)例數(shù)量。

rabbitmq：極高

本身是用Erlang語(yǔ)言寫(xiě)的，并發(fā)性能高。

可在消費(fèi)者中開(kāi)啟多線程，最常用的做法是一個(gè)channel對(duì)應(yīng)一個(gè)消費(fèi)者，每一個(gè)線程把持一個(gè)channel，多個(gè)線程復(fù)用connection的tcp連接，減少性能開(kāi)銷(xiāo)。

當(dāng)rabbitmq隊(duì)列擁有多個(gè)消費(fèi)者的時(shí)候，隊(duì)列收到的消息將以輪詢的分發(fā)方式發(fā)送給消費(fèi)者。每條消息只會(huì)發(fā)送給訂閱列表里的一個(gè)消費(fèi)者，不會(huì)重復(fù)。

這種方式非常適合擴(kuò)展，而且是專門(mén)為并發(fā)程序設(shè)計(jì)的。

如果某些消費(fèi)者的任務(wù)比較繁重，那么可以設(shè)置basicQos限制信道上消費(fèi)者能保持的***未確認(rèn)消息的數(shù)量，在達(dá)到上限時(shí)，rabbitmq不再向這個(gè)消費(fèi)者發(fā)送任何消息。

zeromq：高

rocketmq：高

1>rocketmq限制消費(fèi)者的個(gè)數(shù)少于等于隊(duì)列數(shù)，但是可以在消費(fèi)者中再開(kāi)啟多線程，這一點(diǎn)和kafka是一致的，提高并行度的方法相同。

修改消費(fèi)并行度方法

a) 同一個(gè) ConsumerGroup 下，通過(guò)增加 Consumer 實(shí)例數(shù)量來(lái)提高并行度，超過(guò)訂閱隊(duì)列數(shù)的 Consumer實(shí)例無(wú)效。

b) 提高單個(gè) Consumer 的消費(fèi)并行線程，通過(guò)修改參數(shù)consumeThreadMin、consumeThreadMax

2>同一個(gè)網(wǎng)絡(luò)連接connection，客戶端多個(gè)線程可以同時(shí)發(fā)送請(qǐng)求，連接會(huì)被復(fù)用，減少性能開(kāi)銷(xiāo)。

activemq：高

單個(gè)ActiveMQ的接收和消費(fèi)消息的速度在1萬(wàn)筆/秒(持久化 一般為1-2萬(wàn)， 非持久化 2  萬(wàn)以上)，在生產(chǎn)環(huán)境中部署10個(gè)Activemq就能達(dá)到10萬(wàn)筆/秒以上的性能，部署越多的activemq broker  在MQ上latency也就越低，系統(tǒng)吞吐量也就越高。

以上是“對(duì)比Kafka、RabbitMQ、RocketMQ、ActiveMQ四個(gè)分布式消息隊(duì)列有哪些區(qū)別”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！