溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文介紹了Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 個方面綜合對比作為消息隊列使用時的差異。
Kafka：中。有kafka作者自己寫的書，網上資料也有一些。rabbitmq：多。有一些不錯的書，網上資料多。zeromq：少。沒有專門寫zeromq的書，網上的資料多是一些代碼的實現和簡單介紹。rocketmq：少。沒有專門寫rocketmq的書，網上的資料良莠不齊，官方文檔很簡潔，但是對技術細節沒有過多的描述。activemq：多。沒有專門寫activemq的書，網上資料多。
Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java
Kafka：自己定義的一套…（基于TCP） rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己定義的一套… activemq：OpenWire、STOMP、REST、XMPP、AMQP
Kafka：內存、磁盤、數據庫。支持大量堆積。
kafka的最小存儲單元是分區，一個topic包含多個分區，kafka創建主題時，這些分區會被分配在多個服務器上，通常一個broker一臺服務器。分區首領會均勻地分布在不同的服務器上，分區副本也會均勻的分布在不同的服務器上，確保負載均衡和高可用性，當新的broker加入集群的時候，部分副本會被移動到新的broker上。根據配置文件中的目錄清單，kafka會把新的分區分配給目錄清單里分區數最少的目錄。默認情況下，分區器使用輪詢算法把消息均衡地分布在同一個主題的不同分區中，對于發送時指定了key的情況，會根據key的hashcode取模后的值存到對應的分區中。
rabbitmq：內存、磁盤。支持少量堆積。
rabbitmq的消息分為持久化的消息和非持久化消息，不管是持久化的消息還是非持久化的消息都可以寫入到磁盤。持久化的消息在到達隊列時就寫入到磁盤，并且如果可以，持久化的消息也會在內存中保存一份備份，這樣可以提高一定的性能，當內存吃緊的時候會從內存中清除。非持久化的消息一般只存在于內存中，在內存吃緊的時候會被換入到磁盤中，以節省內存。
引入鏡像隊列機制，可將重要隊列“復制”到集群中的其他broker上，保證這些隊列的消息不會丟失。配置鏡像的隊列，都包含一個主節點master和多個從節點slave,如果master失效，加入時間最長的slave會被提升為新的master，除發送消息外的所有動作都向master發送，然后由master將命令執行結果廣播給各個slave，rabbitmq會讓master均勻地分布在不同的服務器上，而同一個隊列的slave也會均勻地分布在不同的服務器上，保證負載均衡和高可用性。
zeromq：消息發送端的內存或者磁盤中。不支持持久化。
rocketmq：磁盤。支持大量堆積。
commitLog文件存放實際的消息數據，每個commitLog上限是1G，滿了之后會自動新建一個commitLog文件保存數據。ConsumeQueue隊列只存放offset、size、tagcode，非常小，分布在多個broker上。ConsumeQueue相當于CommitLog的索引文件，消費者消費時會從consumeQueue中查找消息在commitLog中的offset，再去commitLog中查找元數據。
ConsumeQueue存儲格式的特性，保證了寫過程的順序寫盤（寫CommitLog文件），大量數據IO都在順序寫同一個commitLog，滿1G了再寫新的。加上rocketmq是累計4K才強制從PageCache中刷到磁盤（緩存），所以高并發寫性能突出。
activemq：內存、磁盤、數據庫。支持少量堆積。
Kafka：支持
rabbitmq：支持。客戶端將信道設置為事務模式，只有當消息被rabbitMq接收，事務才能提交成功，否則在捕獲異常后進行回滾。使用事務會使得性能有所下降
zeromq：不支持
rocketmq：支持
activemq：支持
Kafka：支持負載均衡。
一個broker通常就是一臺服務器節點。對于同一個Topic的不同分區，Kafka會盡力將這些分區分布到不同的Broker服務器上，zookeeper保存了broker、主題和分區的元數據信息。分區首領會處理來自客戶端的生產請求，kafka分區首領會被分配到不同的broker服務器上，讓不同的broker服務器共同分擔任務。
每一個broker都緩存了元數據信息，客戶端可以從任意一個broker獲取元數據信息并緩存起來，根據元數據信息知道要往哪里發送請求。
kafka的消費者組訂閱同一個topic，會盡可能地使得每一個消費者分配到相同數量的分區，分攤負載。
當消費者加入或者退出消費者組的時候，還會觸發再均衡，為每一個消費者重新分配分區，分攤負載。
kafka的負載均衡大部分是自動完成的，分區的創建也是kafka完成的，隱藏了很多細節，避免了繁瑣的配置和人為疏忽造成的負載問題。
發送端由topic和key來決定消息發往哪個分區，如果key為null，那么會使用輪詢算法將消息均衡地發送到同一個topic的不同分區中。如果key不為null，那么會根據key的hashcode取模計算出要發往的分區。
rabbitmq：對負載均衡的支持不好。
消息被投遞到哪個隊列是由交換器和key決定的，交換器、路由鍵、隊列都需要手動創建。
rabbitmq客戶端發送消息要和broker建立連接，需要事先知道broker上有哪些交換器，有哪些隊列。通常要聲明要發送的目標隊列，如果沒有目標隊列，會在broker上創建一個隊列，如果有，就什么都不處理，接著往這個隊列發送消息。假設大部分繁重任務的隊列都創建在同一個broker上，那么這個broker的負載就會過大。（可以在上線前預先創建隊列，無需聲明要發送的隊列，但是發送時不會嘗試創建隊列，可能出現找不到隊列的問題，rabbitmq的備份交換器會把找不到隊列的消息保存到一個專門的隊列中，以便以后查詢使用）
使用鏡像隊列機制建立rabbitmq集群可以解決這個問題，形成master-slave的架構，master節點會均勻分布在不同的服務器上，讓每一臺服務器分攤負載。slave節點只是負責轉發，在master失效時會選擇加入時間最長的slave成為master。
當新節點加入鏡像隊列的時候，隊列中的消息不會同步到新的slave中，除非調用同步命令，但是調用命令后，隊列會阻塞，不能在生產環境中調用同步命令。
當rabbitmq隊列擁有多個消費者的時候，隊列收到的消息將以輪詢的分發方式發送給消費者。每條消息只會發送給訂閱列表里的一個消費者，不會重復。
這種方式非常適合擴展，而且是專門為并發程序設計的。
如果某些消費者的任務比較繁重，那么可以設置basicQos限制信道上消費者能保持的最大未確認消息的數量，在達到上限時，rabbitmq不再向這個消費者發送任何消息。
對于rabbitmq而言，客戶端與集群建立的TCP連接不是與集群中所有的節點建立連接，而是挑選其中一個節點建立連接。
但是rabbitmq集群可以借助HAProxy、LVS技術，或者在客戶端使用算法實現負載均衡，引入負載均衡之后，各個客戶端的連接可以分攤到集群的各個節點之中。
客戶端均衡算法：
輪詢法。按順序返回下一個服務器的連接地址。
加權輪詢法。給配置高、負載低的機器配置更高的權重，讓其處理更多的請求；而配置低、負載高的機器，給其分配較低的權重，降低其系統負載。
隨機法。隨機選取一個服務器的連接地址。
加權隨機法。按照概率隨機選取連接地址。
源地址哈希法。通過哈希函數計算得到的一個數值，用該數值對服務器列表的大小進行取模運算。
最小連接數法。動態選擇當前連接數最少的一臺服務器的連接地址。
zeromq：去中心化，不支持負載均衡。本身只是一個多線程網絡庫。
rocketmq：支持負載均衡。
一個broker通常是一個服務器節點，broker分為master和slave,master和slave存儲的數據一樣，slave從master同步數據。
nameserver與每個集群成員保持心跳，保存著Topic-Broker路由信息，同一個topic的隊列會分布在不同的服務器上。
發送消息通過輪詢隊列的方式發送，每個隊列接收平均的消息量。發送消息指定topic、tags、keys，無法指定投遞到哪個隊列（沒有意義，集群消費和廣播消費跟消息存放在哪個隊列沒有關系）。
tags選填，類似于 Gmail 為每封郵件設置的標簽，方便服務器過濾使用。目前只支 持每個消息設置一個 tag，所以也可以類比為 Notify 的 MessageType 概念。
keys選填，代表這條消息的業務關鍵詞，服務器會根據 keys 創建哈希索引，設置后， 可以在 Console 系統根據 Topic、Keys 來查詢消息，由于是哈希索引，請盡可能 保證 key 唯一，例如訂單號，商品 Id 等。
rocketmq的負載均衡策略規定：Consumer數量應該小于等于Queue數量，如果Consumer超過Queue數量，那么多余的Consumer 將不能消費消息。這一點和kafka是一致的，rocketmq會盡可能地為每一個Consumer分配相同數量的隊列，分攤負載。
activemq：支持負載均衡。可以基于zookeeper實現負載均衡。
Kafka：天然的‘Leader-Slave’無狀態集群，每臺服務器既是Master也是Slave。
分區首領均勻地分布在不同的kafka服務器上，分區副本也均勻地分布在不同的kafka服務器上，所以每一臺kafka服務器既含有分區首領，同時又含有分區副本，每一臺kafka服務器是某一臺kafka服務器的Slave，同時也是某一臺kafka服務器的leader。
kafka的集群依賴于zookeeper，zookeeper支持熱擴展，所有的broker、消費者、分區都可以動態加入移除，而無需關閉服務，與不依靠zookeeper集群的mq相比，這是最大的優勢。
rabbitmq：支持簡單集群，'復制'模式，對高級集群模式支持不好。
rabbitmq的每一個節點，不管是單一節點系統或者是集群中的一部分，要么是內存節點，要么是磁盤節點，集群中至少要有一個是磁盤節點。
在rabbitmq集群中創建隊列，集群只會在單個節點創建隊列進程和完整的隊列信息（元數據、狀態、內容），而不是在所有節點上創建。
引入鏡像隊列，可以避免單點故障，確保服務的可用性，但是需要人為地為某些重要的隊列配置鏡像。
zeromq：去中心化，不支持集群。
rocketmq：常用 多對'Master-Slave' 模式，開源版本需手動切換Slave變成Master
Name Server是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。
Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave的對應關系通過指定相同的BrokerName，不同的BrokerId來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與Name Server集群中的所有節點建立長連接，定時注冊Topic信息到所有Name Server。
Producer與Name Server集群中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master建立長連接，且定時向Master發送心跳。Producer完全無狀態，可集群部署。
Consumer與Name Server集群中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
客戶端先找到NameServer, 然后通過NameServer再找到 Broker。
一個topic有多個隊列，這些隊列會均勻地分布在不同的broker服務器上。rocketmq隊列的概念和kafka的分區概念是基本一致的，kafka同一個topic的分區盡可能地分布在不同的broker上，分區副本也會分布在不同的broker上。
rocketmq集群的slave會從master拉取數據備份，master分布在不同的broker上。
activemq：支持簡單集群模式，比如'主-備'，對高級集群模式支持不好。
Kafka：一般
rabbitmq：好
zeromq：無
rocketmq：無
activemq：一般
Kafka：非常高（分布式）
rabbitmq：高（主從）
zeromq：高
rocketmq：非常高（分布式）
activemq：高（主從）
Kafka：支持at least once、at most once
rabbitmq：支持at least once、at most once
zeromq：只有重傳機制，但是沒有持久化，消息丟了重傳也沒有用。既不是at least once、也不是at most once、更不是exactly only once
rocketmq：支持at least once
activemq：支持at least once
Kafka：極大 Kafka按批次發送消息和消費消息。發送端將多個小消息合并，批量發向Broker，消費端每次取出一個批次的消息批量處理。
rabbitmq：比較大
zeromq：極大
rocketmq：大
rocketMQ接收端可以批量消費消息，可以配置每次消費的消息數，但是發送端不是批量發送。
activemq：比較大
Kafka：基于topic以及按照topic進行正則匹配的發布訂閱模式。
【發送】
發送端由topic和key來決定消息發往哪個分區，如果key為null，那么會使用輪詢算法將消息均衡地發送到同一個topic的不同分區中。如果key不為null，那么會根據key的hashcode取模計算出要發往的分區。
【接收】
1）consumer向群組協調器broker發送心跳來維持他們和群組的從屬關系以及他們對分區的所有權關系，所有權關系一旦被分配就不會改變除非發生再均衡(比如有一個consumer加入或者離開consumer group)，consumer只會從對應的分區讀取消息。
2）kafka限制consumer個數要少于分區個數,每個消息只會被同一個 Consumer Group的一個consumer消費（非廣播）。
3）kafka的 Consumer Group訂閱同一個topic，會盡可能地使得每一個consumer分配到相同數量的分區，不同 Consumer Group訂閱同一個主題相互獨立，同一個消息會被不同的 Consumer Group處理。
rabbitmq：提供了4種：direct, topic ,Headers和fanout。
【發送】
先要聲明一個隊列，這個隊列會被創建或者已經被創建，隊列是基本存儲單元。
由exchange和key決定消息存儲在哪個隊列。
direct>發送到和bindingKey完全匹配的隊列。
topic>路由key是含有"."的字符串，會發送到含有“*”、“#”進行模糊匹配的bingKey對應的隊列。
fanout>與key無關，會發送到所有和exchange綁定的隊列
headers>與key無關，消息內容的headers屬性（一個鍵值對）和綁定鍵值對完全匹配時，會發送到此隊列。此方式性能低一般不用
【接收】
rabbitmq的隊列是基本存儲單元，不再被分區或者分片，對于我們已經創建了的隊列，消費端要指定從哪一個隊列接收消息。
當rabbitmq隊列擁有多個消費者的時候，隊列收到的消息將以輪詢的分發方式發送給消費者。每條消息只會發送給訂閱列表里的一個消費者，不會重復。
這種方式非常適合擴展，而且是專門為并發程序設計的。
如果某些消費者的任務比較繁重，那么可以設置basicQos限制信道上消費者能保持的最大未確認消息的數量，在達到上限時，rabbitmq不再向這個消費者發送任何消息。
zeromq：點對點(p2p)
rocketmq：基于topic/messageTag以及按照消息類型、屬性進行正則匹配的發布訂閱模式。
【發送】
發送消息通過輪詢隊列的方式發送，每個隊列接收平均的消息量。發送消息指定topic、tags、keys，無法指定投遞到哪個隊列（沒有意義，集群消費和廣播消費跟消息存放在哪個隊列沒有關系）。
tags選填，類似于 Gmail 為每封郵件設置的標簽，方便服務器過濾使用。目前只支 持每個消息設置一個 tag，所以也可以類比為 Notify 的 MessageType 概念。
keys選填，代表這條消息的業務關鍵詞，服務器會根據 keys 創建哈希索引，設置后， 可以在 Console 系統根據 Topic、Keys 來查詢消息，由于是哈希索引，請盡可能 保證 key 唯一，例如訂單號，商品 Id 等。
【接收】
1）廣播消費。一條消息被多個Consumer消費，即使Consumer屬于同一個ConsumerGroup，消息也會被ConsumerGroup中的每個Consumer都消費一次。
2）集群消費。一個 Consumer Group中的Consumer實例平均分攤消費消息。例如某個Topic有 9 條消息，其中一個Consumer Group有3個實例，那么每個實例只消費其中的 3 條消息。即每一個隊列都把消息輪流分發給每個consumer。
activemq：點對點(p2p)、廣播（發布-訂閱）
點對點模式，每個消息只有1個消費者；
發布/訂閱模式，每個消息可以有多個消費者。
【發送】
點對點模式：先要指定一個隊列，這個隊列會被創建或者已經被創建。
發布/訂閱模式：先要指定一個topic，這個topic會被創建或者已經被創建。
【接收】
點對點模式：對于已經創建了的隊列，消費端要指定從哪一個隊列接收消息。
發布/訂閱模式：對于已經創建了的topic，消費端要指定訂閱哪一個topic的消息。
Kafka：支持。
設置生產者的max.in.flight.requests.per.connection為1，可以保證消息是按照發送順序寫入服務器的，即使發生了重試。
kafka保證同一個分區里的消息是有序的，但是這種有序分兩種情況
1）key為null，消息逐個被寫入不同主機的分區中，但是對于每個分區依然是有序的
2）key不為null , 消息被寫入到同一個分區，這個分區的消息都是有序。
rabbitmq：不支持
zeromq：不支持
rocketmq：支持
activemq：不支持
Kafka：支持。
1）發送方確認機制
ack=0，不管消息是否成功寫入分區
ack=1，消息成功寫入首領分區后，返回成功
ack=all，消息成功寫入所有分區后，返回成功。
2）接收方確認機制
自動或者手動提交分區偏移量，早期版本的kafka偏移量是提交給Zookeeper的，這樣使得zookeeper的壓力比較大，更新版本的kafka的偏移量是提交給kafka服務器的，不再依賴于zookeeper群組，集群的性能更加穩定。
rabbitmq：支持。
1）發送方確認機制，消息被投遞到所有匹配的隊列后，返回成功。如果消息和隊列是可持久化的，那么在寫入磁盤后，返回成功。支持批量確認和異步確認。
2）接收方確認機制，設置autoAck為false，需要顯式確認，設置autoAck為true，自動確認。
當autoAck為false的時候，rabbitmq隊列會分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經投遞但是沒收到確認的消息。如果一直沒有收到確認信號，并且consumer已經斷開連接，rabbitmq會安排這個消息重新進入隊列，投遞給原來的消費者或者下一個消費者。
未確認的消息不會有過期時間，如果一直沒有確認，并且沒有斷開連接，rabbitmq會一直等待，rabbitmq允許一條消息處理的時間可以很久很久。
zeromq：支持
rocketmq：支持
activemq：支持
Kafka：支持指定分區offset位置的回溯
rabbitmq：不支持
zeromq：不支持
rocketmq：支持指定時間點的回溯
activemq：不支持
Kafka：不支持，但是可以實現。
kafka支持指定分區offset位置的回溯，可以實現消息重試。
rabbitmq：不支持，但是可以利用消息確認機制實現。
rabbitmq接收方確認機制，設置autoAck為false。
當autoAck為false的時候，rabbitmq隊列會分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經投遞但是沒收到確認的消息。如果一直沒有收到確認信號，并且consumer已經斷開連接，rabbitmq會安排這個消息重新進入隊列，投遞給原來的消費者或者下一個消費者。
zeromq：不支持
rocketmq：支持。
消息消費失敗的大部分場景下，立即重試99%都會失敗，所以rocketmq的策略是在消費失敗時定時重試，每次時間間隔相同。
1、發送端的 send 方法本身支持內部重試，重試邏輯如下：
a)至多重試3次；
b)如果發送失敗，則輪轉到下一個broker；
c)這個方法的總耗時不超過sendMsgTimeout 設置的值，默認 10s，超過時間不在重試。
2、接收端。
Consumer 消費消息失敗后，要提供一種重試機制，令消息再消費一次。Consumer 消費消息失敗通常可以分為以下兩種情況：
由于消息本身的原因，例如反序列化失敗，消息數據本身無法處理（例如話費充值，當前消息的手機號被
注銷，無法充值）等。定時重試機制，比如過 10s 秒后再重試。
由于依賴的下游應用服務不可用，例如 db 連接不可用，外系統網絡不可達等。
即使跳過當前失敗的消息，消費其他消息同樣也會報錯。這種情況可以 sleep 30s，再消費下一條消息，減輕 Broker 重試消息的壓力。
activemq：不支持
Kafka：高
一個線程一個消費者，kafka限制消費者的個數要小于等于分區數，如果要提高并行度，可以在消費者中再開啟多線程，或者增加consumer實例數量。
rabbitmq：極高
本身是用Erlang語言寫的，并發性能高。
可在消費者中開啟多線程，最常用的做法是一個channel對應一個消費者，每一個線程把持一個channel，多個線程復用connection的tcp連接，減少性能開銷。
當rabbitmq隊列擁有多個消費者的時候，隊列收到的消息將以輪詢的分發方式發送給消費者。每條消息只會發送給訂閱列表里的一個消費者，不會重復。
這種方式非常適合擴展，而且是專門為并發程序設計的。
如果某些消費者的任務比較繁重，那么可以設置basicQos限制信道上消費者能保持的最大未確認消息的數量，在達到上限時，rabbitmq不再向這個消費者發送任何消息。
zeromq：高
rocketmq：高
1、rocketmq限制消費者的個數少于等于隊列數，但是可以在消費者中再開啟多線程，這一點和kafka是一致的，提高并行度的方法相同。
修改消費并行度方法
a) 同一個 ConsumerGroup 下，通過增加 Consumer 實例數量來提高并行度，超過訂閱隊列數的 Consumer實例無效。
b) 提高單個 Consumer 的消費并行線程，通過修改參數consumeThreadMin、consumeThreadMax
2、同一個網絡連接connection，客戶端多個線程可以同時發送請求，連接會被復用，減少性能開銷。
activemq：高
單個ActiveMQ的接收和消費消息的速度在1萬筆/秒（持久化 一般為1-2萬， 非持久化 2 萬以上），在生產環境中部署10個Activemq就能達到10萬筆/秒以上的性能，部署越多的activemq broker 在MQ上latency也就越低，系統吞吐量也就越高。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
