分布式消息隊(duì)列差異化總結(jié)，太全了！

本文將對(duì)Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ從17 個(gè)方面綜合對(duì)比作為消息隊(duì)列使用時(shí)的差異。

• Kafka：資料數(shù)量中等。有Kafka作者自己寫的書，網(wǎng)上資料也有一些。

• RabbitMQ：資料數(shù)量多。有一些不錯(cuò)的書，網(wǎng)上資料多。

• ZeroMQ：資料數(shù)量少。專門寫ZeroMQ的書較少，網(wǎng)上的資料多是一些代碼的實(shí)現(xiàn)和簡(jiǎn)單介紹。

• RocketMQ：資料數(shù)量少。專門寫RocketMQ的書目前有了兩本；網(wǎng)上的資料良莠不齊，官方文檔很簡(jiǎn)潔，但是對(duì)技術(shù)細(xì)節(jié)沒有過多的描述。

• ActiveMQ：資料數(shù)量多。沒有專門寫ActiveMQ的書，網(wǎng)上資料多。

• Kafka：Scala

• RabbitMQ：Erlang

• ZeroMQ：C

• RocketMQ：Java

• ActiveMQ：Java

• Kafka：自己定義的一套…（基于TCP）?

• RabbitMQ：AMQP?

• ZeroMQ：TCP、UDP?

• RocketMQ：自己定義的一套…?

• ActiveMQ：OpenWire、STOMP、REST、XMPP、AMQP

內(nèi)存、磁盤、數(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ū)中。

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

RabbitMQ的消息分為持久化的消息和非持久化消息，不管是持久化的消息還是非持久化的消息都可以寫入到磁盤。

持久化的消息在到達(dá)隊(duì)列時(shí)就寫入到磁盤，并且如果可以，持久化的消息也會(huì)在內(nèi)存中保存一份備份，這樣可以提高一定的性能，當(dāng)內(nèi)存吃緊的時(shí)候會(huì)從內(nèi)存中清除。

非持久化的消息一般只存在于內(nèi)存中，在內(nèi)存吃緊的時(shí)候會(huì)被換入到磁盤中，以節(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ù)載均衡和高可用性。

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

磁盤。支持大量堆積。

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ǔ)格式的特性，保證了寫過程的順序?qū)懕P（寫CommitLog文件），大量數(shù)據(jù)IO都在順序?qū)懲粋€(gè)commitLog，滿1G了再寫新的。

加上RocketMQ是累計(jì)4K才強(qiáng)制從PageCache中刷到磁盤（緩存），所以高并發(fā)寫性能突出。

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

• Kafka：支持

• RabbitMQ：支持。

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

• ZeroMQ：不支持

• RocketMQ：支持

• ActiveMQ：支持

支持負(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ù)載問題。

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ū)。

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

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

RabbitMQ客戶端發(fā)送消息要和broker建立連接，需要事先知道broker上有哪些交換器，有哪些隊(duì)列。

通常要聲明要發(fā)送的目標(biāo)隊(duì)列，如果沒有目標(biāo)隊(duì)列，會(huì)在broker上創(chuàng)建一個(gè)隊(duì)列，如果有，就什么都不處理，接著往這個(gè)隊(duì)列發(fā)送消息。假設(shè)大部分繁重任務(wù)的隊(duì)列都創(chuàng)建在同一個(gè)broker上，那么這個(gè)broker的負(fù)載就會(huì)過大。

可以在上線前預(yù)先創(chuàng)建隊(duì)列，無(wú)需聲明要發(fā)送的隊(duì)列，但是發(fā)送時(shí)不會(huì)嘗試創(chuàng)建隊(duì)列，可能出現(xiàn)找不到隊(duì)列的問題，RabbitMQ的備份交換器會(huì)把找不到隊(duì)列的消息保存到一個(gè)專門的隊(duì)列中，以便以后查詢使用。

使用鏡像隊(duì)列機(jī)制建立RabbitMQ集群可以解決這個(gè)問題，形成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ò)展，而且是專門為并發(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)之中。

客戶端均衡算法：

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

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

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

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

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

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

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

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

• tags選填，類似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過濾使用。目前只支 持每個(gè)消息設(shè)置一個(gè) tag，所以也可以類比為 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超過Queue數(shù)量，那么多余的Consumer 將不能消費(fèi)消息。

這一點(diǎn)和Kafka是一致的，RocketMQ會(huì)盡可能地為每一個(gè)Consumer分配相同數(shù)量的隊(duì)列，分?jǐn)傌?fù)載。

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

天然的‘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ì)。

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

RabbitMQ的每一個(gè)節(jié)點(diǎn)，不管是單一節(jié)點(diǎn)系統(tǒng)或者是集群中的一部分，要么是內(nèi)存節(jié)點(diǎn)，要么是磁盤節(jié)點(diǎn)，集群中至少要有一個(gè)是磁盤節(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ì)列配置鏡像。

去中心化，不支持集群。

常用 多對(duì)'Master-Slave' 模式，開源版本需手動(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)系通過指定相同的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, 然后通過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上。

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

• Kafka：一般

• RabbitMQ：好

• ZeroMQ：無(wú)

• RocketMQ：有管理后臺(tái), 但不是項(xiàng)目里自帶, 需要自己?jiǎn)?dòng)一個(gè)單獨(dú)的管理后臺(tái)實(shí)例

• ActiveMQ：一般

• Kafka：非常高（分布式）

• RabbitMQ：高（主從）

• ZeroMQ：高

• RocketMQ：非常高（分布式）

• ActiveMQ：高（主從）

• Kafka：支持at least once、at most once

• RabbitMQ：支持at least once、at most once

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

• RocketMQ：支持at least once

• ActiveMQ：支持at least once

• Kafka：極大

  Kafka按批次發(fā)送消息和消費(fèi)消息。發(fā)送端將多個(gè)小消息合并，批量發(fā)向Broker，消費(fèi)端每次取出一個(gè)批次的消息批量處理。?

• RabbitMQ：比較大

• ZeroMQ：極大

• RocketMQ：大

  RocketMQ接收端可以批量消費(fèi)消息，可以配置每次消費(fèi)的消息數(shù)，但是發(fā)送端不是批量發(fā)送。

• ActiveMQ：比較大

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

1）發(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ū)。

2）接收

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

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

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

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

1）發(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ì)列。此方式性能低一般不用

2）接收

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ò)展，而且是專門為并發(fā)程序設(shè)計(jì)的。

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

點(diǎn)對(duì)點(diǎn)(p2p)。

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

1）發(fā)送

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

• tags選填，類似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過濾使用。目前只支 持每個(gè)消息設(shè)置一個(gè) tag，所以也可以類比為 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 等。

2）接收

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

• 集群消費(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。

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

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

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

1）發(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)建。

2）接收

• 點(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ū)里的消息是有序的，但是這種有序分兩種情況：

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

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

• RabbitMQ：不支持

• ZeroMQ：不支持

• RocketMQ：支持

• ActiveMQ：不支持

支持。

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

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

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

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

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

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

支持。

1）發(fā)送方確認(rèn)機(jī)制，消息被投遞到所有匹配的隊(duì)列后，返回成功。如果消息和隊(duì)列是可持久化的，那么在寫入磁盤后，返回成功。支持批量確認(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)投遞但是沒收到確認(rèn)的消息。

如果一直沒有收到確認(rèn)信號(hào)，并且consumer已經(jīng)斷開連接，RabbitMQ會(huì)安排這個(gè)消息重新進(jìn)入隊(duì)列，投遞給原來(lái)的消費(fèi)者或者下一個(gè)消費(fèi)者。

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

支持。

支持。

支持。

• Kafka：支持指定分區(qū)offset位置的回溯

• RabbitMQ：不支持

• ZeroMQ：不支持

• RocketMQ：支持指定時(shí)間點(diǎn)的回溯

• ActiveMQ：不支持

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

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

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

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

當(dāng)autoAck為false的時(shí)候，RabbitMQ隊(duì)列會(huì)分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經(jīng)投遞但是沒收到確認(rèn)的消息。

如果一直沒有收到確認(rèn)信號(hào)，并且consumer已經(jīng)斷開連接，RabbitMQ會(huì)安排這個(gè)消息重新進(jìn)入隊(duì)列，投遞給原來(lái)的消費(fèi)者或者下一個(gè)消費(fèi)者。

不支持。

支持。

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

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

• 至多重試3次；

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

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

2）接收端。

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

• 由于消息本身的原因，例如反序列化失敗，消息數(shù)據(jù)本身無(wú)法處理（例如話費(fèi)充值，當(dāng)前消息的手機(jī)號(hào)被注銷，無(wú)法充值）等。定時(shí)重試機(jī)制，比如過 10s 秒后再重試。

• 由于依賴的下游應(yīng)用服務(wù)不可用，例如 db 連接不可用，外系統(tǒng)網(wǎng)絡(luò)不可達(dá)等。即使跳過當(dāng)前失敗的消息，消費(fèi)其他消息同樣也會(huì)報(bào)錯(cuò)。這種情況可以 sleep 30s，再消費(fèi)下一條消息，減輕 Broker 重試消息的壓力。

不支持。

并發(fā)度高。

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

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

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

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

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

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

并發(fā)度高。

并發(fā)度高。

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

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

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

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

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

并發(fā)度高。

單個(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)吞吐量也就越高。