常用消息中間件17個維度全方位對比-創(chuàng)新互聯(lián)

本文介紹了Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 個方面綜合對比作為消息隊列使用時的差異。

創(chuàng)新互聯(lián)建站始終堅持【策劃先行，效果至上】的經(jīng)營理念，通過多達10年累計超上千家客戶的網(wǎng)站建設總結了一套系統(tǒng)有效的全網(wǎng)營銷推廣解決方案，現(xiàn)已廣泛運用于各行各業(yè)的客戶，其中包括：成都效果圖設計等企業(yè)，備受客戶贊譽。

一 資料文檔

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

二 開發(fā)語言

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

四 消息存儲

Kafka：內存、磁盤、數(shù)據(jù)庫。支持大量堆積。

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

rabbitmq：內存、磁盤。支持少量堆積。

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

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

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

rocketmq：磁盤。支持大量堆積。

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

ConsumeQueue存儲格式的特性，保證了寫過程的順序寫盤（寫CommitLog文件），大量數(shù)據(jù)IO都在順序寫同一個commitLog，滿1G了再寫新的。加上rocketmq是累計4K才強制從PageCache中刷到磁盤（緩存），所以高并發(fā)寫性能突出。

activemq：內存、磁盤、數(shù)據(jù)庫。支持少量堆積。

五 消息事務

Kafka：支持

rabbitmq：支持?？蛻舳藢⑿诺涝O置為事務模式，只有當消息被rabbitMq接收，事務才能提交成功，否則在捕獲異常后進行回滾。使用事務會使得性能有所下降

  • zeromq：不支持

  • rocketmq：支持

  • activemq：支持

六 負載均衡

Kafka：支持負載均衡。

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

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

kafka的消費者組訂閱同一個topic，會盡可能地使得每一個消費者分配到相同數(shù)量的分區(qū)，分攤負載。

當消費者加入或者退出消費者組的時候，還會觸發(fā)再均衡，為每一個消費者重新分配分區(qū)，分攤負載。

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

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

rabbitmq：對負載均衡的支持不好。

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

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

使用鏡像隊列機制建立rabbitmq集群可以解決這個問題，形成master-slave的架構，master節(jié)點會均勻分布在不同的服務器上，讓每一臺服務器分攤負載。slave節(jié)點只是負責轉發(fā)，在master失效時會選擇加入時間最長的slave成為master。

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

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

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

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

對于rabbitmq而言，客戶端與集群建立的TCP連接不是與集群中所有的節(jié)點建立連接，而是挑選其中一個節(jié)點建立連接。

但是rabbitmq集群可以借助HAProxy、LVS技術，或者在客戶端使用算法實現(xiàn)負載均衡，引入負載均衡之后，各個客戶端的連接可以分攤到集群的各個節(jié)點之中。

客戶端均衡算法：

  • 輪詢法。按順序返回下一個服務器的連接地址。

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

  • 隨機法。隨機選取一個服務器的連接地址。

  • 加權隨機法。按照概率隨機選取連接地址。

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

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

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

rocketmq：支持負載均衡。

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

nameserver與每個集群成員保持心跳，保存著Topic-Broker路由信息，同一個topic的隊列會分布在不同的服務器上。

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

tags選填，類似于 Gmail 為每封郵件設置的標簽，方便服務器過濾使用。目前只支 持每個消息設置一個 tag，所以也可以類比為 Notify 的 MessageType 概念。

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

rocketmq的負載均衡策略規(guī)定：Consumer數(shù)量應該小于等于Queue數(shù)量，如果Consumer超過Queue數(shù)量，那么多余的Consumer 將不能消費消息。這一點和kafka是一致的，rocketmq會盡可能地為每一個Consumer分配相同數(shù)量的隊列，分攤負載。

activemq：支持負載均衡?？梢曰趜ookeeper實現(xiàn)負載均衡。

七 集群方式

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

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

kafka的集群依賴于zookeeper，zookeeper支持熱擴展，所有的broker、消費者、分區(qū)都可以動態(tài)加入移除，而無需關閉服務，與不依靠zookeeper集群的mq相比，這是大的優(yōu)勢。

rabbitmq：支持簡單集群，'復制'模式，對高級集群模式支持不好。

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

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

引入鏡像隊列，可以避免單點故障，確保服務的可用性，但是需要人為地為某些重要的隊列配置鏡像。

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

rocketmq：常用 多對'Master-Slave' 模式，開源版本需手動切換Slave變成Master

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

Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave的對應關系通過指定相同的BrokerName，不同的BrokerId來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與Name Server集群中的所有節(jié)點建立長連接，定時注冊Topic信息到所有Name Server。

Producer與Name Server集群中的其中一個節(jié)點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master建立長連接，且定時向Master發(fā)送心跳。Producer完全無狀態(tài)，可集群部署。

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

客戶端先找到NameServer, 然后通過NameServer再找到 Broker。

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

rocketmq集群的slave會從master拉取數(shù)據(jù)備份，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

十一 吞吐量TPS

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

  • rabbitmq：比較大

  • zeromq：極大

  • rocketmq：大

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

activemq：比較大

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

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

【發(fā)送】

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

【接收】

1）consumer向群組協(xié)調器broker發(fā)送心跳來維持他們和群組的從屬關系以及他們對分區(qū)的所有權關系，所有權關系一旦被分配就不會改變除非發(fā)生再均衡(比如有一個consumer加入或者離開consumer group)，consumer只會從對應的分區(qū)讀取消息。

2）kafka限制consumer個數(shù)要少于分區(qū)個數(shù),每個消息只會被同一個 Consumer Group的一個consumer消費（非廣播）。

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

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

【發(fā)送】

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

由exchange和key決定消息存儲在哪個隊列。

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

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

fanout>與key無關，會發(fā)送到所有和exchange綁定的隊列

headers>與key無關，消息內容的headers屬性（一個鍵值對）和綁定鍵值對完全匹配時，會發(fā)送到此隊列。此方式性能低一般不用

【接收】

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

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

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

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

zeromq：點對點(p2p)

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

【發(fā)送】

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

tags選填，類似于 Gmail 為每封郵件設置的標簽，方便服務器過濾使用。目前只支 持每個消息設置一個 tag，所以也可以類比為 Notify 的 MessageType 概念。

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

【接收】

1）廣播消費。一條消息被多個Consumer消費，即使Consumer屬于同一個ConsumerGroup，消息也會被ConsumerGroup中的每個Consumer都消費一次。

2）集群消費。一個 Consumer Group中的Consumer實例平均分攤消費消息。例如某個Topic有 9 條消息，其中一個Consumer Group有3個實例，那么每個實例只消費其中的 3 條消息。即每一個隊列都把消息輪流分發(fā)給每個consumer。

activemq：點對點(p2p)、廣播（發(fā)布-訂閱）

點對點模式，每個消息只有1個消費者；

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

【發(fā)送】

點對點模式：先要指定一個隊列，這個隊列會被創(chuàng)建或者已經(jīng)被創(chuàng)建。

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

【接收】

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

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

十三 順序消息

Kafka：支持。

設置生產(chǎn)者的max.in.flight.requests.per.connection為1，可以保證消息是按照發(fā)送順序寫入服務器的，即使發(fā)生了重試。

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

1）key為null，消息逐個被寫入不同主機的分區(qū)中，但是對于每個分區(qū)依然是有序的

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

  • rabbitmq：不支持

  • zeromq：不支持

  • rocketmq：支持

  • activemq：不支持

十四 消息確認

Kafka：支持。

1）發(fā)送方確認機制

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

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

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

2）接收方確認機制

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

rabbitmq：支持。

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

2）接收方確認機制，設置autoAck為false，需要顯式確認，設置autoAck為true，自動確認。

當autoAck為false的時候，rabbitmq隊列會分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經(jīng)投遞但是沒收到確認的消息。如果一直沒有收到確認信號，并且consumer已經(jīng)斷開連接，rabbitmq會安排這個消息重新進入隊列，投遞給原來的消費者或者下一個消費者。

未確認的消息不會有過期時間，如果一直沒有確認，并且沒有斷開連接，rabbitmq會一直等待，rabbitmq允許一條消息處理的時間可以很久很久。

  • zeromq：支持

  • rocketmq：支持

  • activemq：支持

十五 消息回溯

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

  • rabbitmq：不支持

  • zeromq：不支持

  • rocketmq：支持指定時間點的回溯

  • activemq：不支持

十六 消息重試

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

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

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

rabbitmq接收方確認機制，設置autoAck為false。

當autoAck為false的時候，rabbitmq隊列會分成兩部分，一部分是等待投遞給consumer的消息，一部分是已經(jīng)投遞但是沒收到確認的消息。如果一直沒有收到確認信號，并且consumer已經(jīng)斷開連接，rabbitmq會安排這個消息重新進入隊列，投遞給原來的消費者或者下一個消費者。

zeromq：不支持

rocketmq：支持。

消息消費失敗的大部分場景下，立即重試99%都會失敗，所以rocketmq的策略是在消費失敗時定時重試，每次時間間隔相同。

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

a)至多重試3次；

b)如果發(fā)送失敗，則輪轉到下一個broker；

c)這個方法的總耗時不超過sendMsgTimeout 設置的值，默認 10s，超過時間不在重試。

2、接收端。

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

  1. 由于消息本身的原因，例如反序列化失敗，消息數(shù)據(jù)本身無法處理（例如話費充值，當前消息的手機號被

注銷，無法充值）等。定時重試機制，比如過 10s 秒后再重試。

  1. 由于依賴的下游應用服務不可用，例如 db 連接不可用，外系統(tǒng)網(wǎng)絡不可達等。

即使跳過當前失敗的消息，消費其他消息同樣也會報錯。這種情況可以 sleep 30s，再消費下一條消息，減輕 Broker 重試消息的壓力。

activemq：不支持

十七 并發(fā)度

Kafka：高

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

rabbitmq：極高

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

可在消費者中開啟多線程，最常用的做法是一個channel對應一個消費者，每一個線程把持一個channel，多個線程復用connection的tcp連接，減少性能開銷。

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

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

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

zeromq：高

rocketmq：高

1、rocketmq限制消費者的個數(shù)少于等于隊列數(shù)，但是可以在消費者中再開啟多線程，這一點和kafka是一致的，提高并行度的方法相同。

修改消費并行度方法

a) 同一個 ConsumerGroup 下，通過增加 Consumer 實例數(shù)量來提高并行度，超過訂閱隊列數(shù)的 Consumer實例無效。

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

2、同一個網(wǎng)絡連接connection，客戶端多個線程可以同時發(fā)送請求，連接會被復用，減少性能開銷。

activemq：高

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

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準確進行流量調度，確保服務器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務器買多久送多久。

本文題目：常用消息中間件17個維度全方位對比-創(chuàng)新互聯(lián)
文章鏈接：http://muchs.cn/article22/eegcc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、網(wǎng)站營銷、Google、網(wǎng)站設計公司、企業(yè)網(wǎng)站制作、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都做網(wǎng)站