Hi! 我是小小，我們今天又見面了，今天主要內(nèi)容是從十七個方面對比kafka，rabbitmq，zeromq，rocketmq，activemq，更加方便你的技術(shù)選型哦！

資料文檔

1. kafaka：在kafka中，有作者自己寫的書，網(wǎng)上的資料也有一點
2. rabbitmq，多，有很多不錯的數(shù)，網(wǎng)絡(luò)上資料也多。
3. zeromq，少，沒有專門寫zeromq的書，網(wǎng)上的資料多是代碼實現(xiàn)和簡單介紹。
4. rocketmq，少，沒有專門寫rocketmq的數(shù)，網(wǎng)絡(luò)上的良莠不齊，官方文檔簡單，但是對技術(shù)細節(jié)沒有過多的描述。
5. activemq，多，沒有專門寫activemq的書，網(wǎng)上資料多。

開發(fā)語言

kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：Java activemq：Java

支持的協(xié)議

1. kafka 自己定義的一套，基于TCP
2. rabbitmq：AMQP
3. zeromq：TCP，UDP
4. rocketmq：自己定義的一套
5. activemq：OpenWire，STOMP，REST，XMPP，AMQP

消息存儲

1. kafka：內(nèi)存，磁盤，數(shù)據(jù)庫，支持大量堆積 kafka 的最小存儲單元是分區(qū)，一個topic包含多個分區(qū)，kafka創(chuàng)建分區(qū)的時候，這些分區(qū)會被分配在多個服務(wù)器上，通常一個節(jié)點是一臺服務(wù)器，分區(qū)會均勻的分布在不同的服務(wù)器上，分區(qū)的副本也會均勻的分布在不同的服務(wù)器上，確保負載均衡以及高可用。當新的節(jié)點加入集群的時候，部分副本會自動遷移到新的節(jié)點上，根據(jù)配置文件中的目錄，會自己吧新的分區(qū)分配非目錄分區(qū)里分區(qū)數(shù)最少的目錄。
2. rabbitmq: 內(nèi)存，磁盤，支持少量堆積 rabbitmq的消息分為持久化消息和非持久化消息，不管是否是不是持久化消息，其都會寫入到磁盤里，其中，持久化的消息也同樣會在內(nèi)存里保存一份，這樣做的目的是提高性能。引入了鏡像隊列機制，可以吧重要的隊列復(fù)制到集群中其他節(jié)點上，保證這些隊列消息不丟失，配置鏡像隊列，包含一個主節(jié)點，master和從節(jié)點slave，如果master節(jié)點失效，從節(jié)點會自動變成主節(jié)點。rabbitmq會讓master均勻的分布在不同的服務(wù)器上，而同一個隊列的slave也會均勻的分布在不同的服務(wù)器上，保證負載均衡和高可用。
3. zeromq：消息發(fā)送端的內(nèi)存或者磁盤中保存，不支持持久化。
4. rocketmq：磁盤，支持大量堆積。日志文件存放的是實際的消息數(shù)據(jù)，每個日志文件上限是1G，滿看之后會自動新建一個日志文件保存數(shù)據(jù)。ConsumeQueue隊列只存放offset，size，tagcode數(shù)據(jù)，非常小，分布在多個節(jié)點上。其中consumequeue相當于日志文件的索引文件，消費者消費的時候，從consumequeue中查找消息的在日志文件中查找到offset，再去commitlog中查找元數(shù)據(jù)。
5. activemq：內(nèi)存，磁盤，數(shù)據(jù)庫，支持少量堆積。

消息事物

1. kafka 支持
2. rabbitmq：支持，客戶端吧信道設(shè)置為事物模式以后，只有當消息被rabbitmq接收以后，事物才能提交成功，否則進行回滾，
3. zeromq：不支持
4. rocketmq：支持
5. activemq：支持

負載均衡

kafka

1. 一個節(jié)點通常就是一臺服務(wù)器節(jié)點。對于同一個Topic的不同分區(qū)，Kafka會盡力將這些分區(qū)分布到不同的節(jié)點服務(wù)器上，zookeeper保存了節(jié)點信息、主題和分區(qū)的元數(shù)據(jù)信息。分區(qū)首領(lǐng)會處理來自客戶端的生產(chǎn)請求，kafka分區(qū)首領(lǐng)會被分配到不同的節(jié)點服務(wù)器上，讓不同的節(jié)點服務(wù)器共同分擔任務(wù)。每一個節(jié)點都緩存了元數(shù)據(jù)信息，客戶端可以從任意一個節(jié)點獲取元數(shù)據(jù)信息并緩存起來，根據(jù)元數(shù)據(jù)信息知道要往哪里發(fā)送請求。
2. kafka的消費者組訂閱同一個topic，會盡可能地使得每一個消費者分配到相同數(shù)量的分區(qū)，分攤負載。
3. 當消費者加入或者退出消費者組的時候，還會觸發(fā)再均衡，為每一個消費者重新分配分區(qū)，分攤負載。

kafka的負載均衡大部分是自動完成的，分區(qū)的創(chuàng)建也是kafka完成的，隱藏了很多細節(jié)，避免了繁瑣的配置和人為疏忽造成的負載問題。4. 發(fā)送端由topic和key來決定消息發(fā)往哪個分區(qū)，如果key為null，那么會使用輪詢算法將消息均衡地發(fā)送到同一個topic的不同分區(qū)中。如果key不為null，那么會根據(jù)key的hashcode取模計算出要發(fā)往的分區(qū)。

rabbitmq

對負債均衡支持不好

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

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

當新節(jié)點加入鏡像隊列的時候，隊列中的消息不會同步到新的slave中，除非調(diào)用同步命令，但是調(diào)用命令后，隊列會阻塞，不能在生產(chǎn)環(huán)境中調(diào)用同步命令。2. 當rabbitmq隊列擁有多個消費者的時候，隊列收到的消息將以輪詢的分發(fā)方式發(fā)送給消費者。每條消息只會發(fā)送給訂閱列表里的一個消費者，不會重復(fù)。

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

如果某些消費者的任務(wù)比較繁重，那么可以設(shè)置basicQos限制信道上消費者能保持的最大未確認消息的數(shù)量，在達到上限時，rabbitmq不再向這個消費者發(fā)送任何消息。3. 對于rabbitmq而言，客戶端與集群建立的TCP連接不是與集群中所有的節(jié)點建立連接，而是挑選其中一個節(jié)點建立連接。

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

rocketmq

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

activemq

支持負載均衡，可以基于zookeeper實現(xiàn)負債均衡

管理界面

1. kafka：一般
2. rabbitmq：好
3. zeromq：無
4. rocketmq：無
5. activemq：一般

可用性

1. kafka：非常高
2. rabbitmq：高
3. zeromq: 高
4. rocketmq：非常高
5. activemq：高

吞吐量

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

順序消息

kafka

Kafka：支持。

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

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

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

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

rabbitmq

rabbitmq：不支持

zeromq

zeromq：不支持

rocketmq

rocketmq：支持

activemq

activemq：不支持

并發(fā)度

kafka

Kafka：高

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

rabbitmq

rabbitmq：極高

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

zeromq

zeromq：高

rocketmq

rocketmq：高

1. rocketmq限制消費者的個數(shù)少于等于隊列數(shù)，但是可以在消費者中再開啟多線程，這一點和kafka是一致的，提高并行度的方法相同。
2. 同一個網(wǎng)絡(luò)連接connection，客戶端多個線程可以同時發(fā)送請求，連接會被復(fù)用，減少性能開銷。

activemq

activemq：高

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

0、大寫的服，看完這篇你還不懂RocketMQ算我輸