17 個方面，綜合對比 Kafka、RabbitMQ、RocketMQ、ActiveMQ 四個分布式消息隊列
本文將從，Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ 17 個方面綜合比照作為音訊行列運用時的差異。
良心引薦：如下 10 篇文章，是艿艿寫的四種 MQ 在 Spring Boot、Spring Cloud 的實戰(zhàn)文章~~~
良心引薦：如下 10 篇文章，是艿艿寫的四種 MQ 在 Spring Boot、Spring Cloud 的實戰(zhàn)文章~~~
一、材料文檔
Kafka：中。有kafka作者自己寫的書，網(wǎng)上材料也有一些。rabbitmq：多。有一些不錯的書，網(wǎng)上材料多。zeromq：少。沒有專門寫zeromq的書，網(wǎng)上的材料多是一些代碼的完成和簡略介紹。rocketmq：少。沒有專門寫rocketmq的書，網(wǎng)上的材料良莠不齊，官方文檔很簡潔，可是對技能細節(jié)沒有過多的描繪。activemq：多。沒有專門寫activemq的書，網(wǎng)上材料多。
二、開發(fā)言語
Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java
三、支撐的協(xié)議
Kafka：自己界說的一套...（依據(jù)TCP） rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己界說的一套... activemq：OpenWire、STOMP、REST、XMPP、AMQP
四、音訊存儲
Kafka：內(nèi)存、磁盤、數(shù)據(jù)庫。支撐許多堆積。
kafka的最小存儲單元是分區(qū)，一個topic包括多個分區(qū)，kafka創(chuàng)立主題時，這些分區(qū)會被分配在多個服務(wù)器上，一般一個broker一臺服務(wù)器。分區(qū)首體會均勻地散布在不同的服務(wù)器上，分區(qū)副本也會均勻的散布在不同的服務(wù)器上，確保負(fù)載均衡和高可用性，當(dāng)新的broker參加集群的時分，部分副本會被移動到新的broker上。依據(jù)裝備文件中的目錄清單，kafka會把新的分區(qū)分配給目錄清單里分區(qū)數(shù)最少的目錄。默認(rèn)狀況下，分區(qū)器運用輪詢算法把音訊均衡地散布在同一個主題的不同分區(qū)中，關(guān)于發(fā)送時指定了key的狀況，會依據(jù)key的hashcode取模后的值存到對應(yīng)的分區(qū)中。
rabbitmq：內(nèi)存、磁盤。支撐少量堆積。
rabbitmq的音訊分為耐久化的音訊和非耐久化音訊，不管是耐久化的音訊還是非耐久化的音訊都能夠?qū)懭氲酱疟P。耐久化的音訊在到達行列時就寫入到磁盤，并且假如能夠，耐久化的音訊也會在內(nèi)存中保存一份備份，這樣能夠進步必定的功能，當(dāng)內(nèi)存吃緊的時分會從內(nèi)存中清除。非耐久化的音訊一般只存在于內(nèi)存中，在內(nèi)存吃緊的時分會被換入到磁盤中，以節(jié)省內(nèi)存。
引進鏡像行列機制，可將重要行列“仿制”到集群中的其他broker上，確保這些行列的音訊不會丟掉。裝備鏡像的行列，都包括一個主節(jié)點master和多個從節(jié)點slave,假如master失效，參加時刻最長的slave會被提升為新的master，除發(fā)送音訊外的一切動作都向master發(fā)送，然后由master將指令履行結(jié)果播送給各個slave，rabbitmq會讓master均勻地散布在不同的服務(wù)器上，而同一個行列的slave也會均勻地散布在不同的服務(wù)器上，確保負(fù)載均衡和高可用性。
zeromq：音訊發(fā)送端的內(nèi)存或許磁盤中。不支撐耐久化。
rocketmq：磁盤。支撐許多堆積。
commitLog文件寄存實際的音訊數(shù)據(jù)，每個commitLog上限是1G，滿了之后會主動新建一個commitLog文件保存數(shù)據(jù)。ConsumeQueue行列只寄存offset、size、tagcode，十分小，散布在多個broker上。ConsumeQueue相當(dāng)于CommitLog的索引文件，顧客消費時會從consumeQueue中查找音訊在commitLog中的offset，再去commitLog中查找元數(shù)據(jù)。
ConsumeQueue存儲格式的特性，確保了寫過程的次序?qū)懕P（寫CommitLog文件），許多數(shù)據(jù)IO都在次序?qū)懲粋€commitLog，滿1G了再寫新的。加上rocketmq是累計4K才強制從PageCache中刷到磁盤（緩存），所以高并發(fā)寫功能突出。
activemq：內(nèi)存、磁盤、數(shù)據(jù)庫。支撐少量堆積。
五、音訊事務(wù)
Kafka：支撐 rabbitmq：支撐?？蛻舳藢⑿诺涝O(shè)置為事務(wù)辦法，只要當(dāng)音訊被rabbitMq接納，事務(wù)才能提交成功，否則在捕獲異常后進行回滾。運用事務(wù)會使得功能有所下降 zeromq：不支撐 rocketmq：支撐 activemq：支撐
六、負(fù)載均衡
Kafka：支撐負(fù)載均衡。
1>一個broker一般就是一臺服務(wù)器節(jié)點。關(guān)于同一個Topic的不同分區(qū)，Kafka會極力將這些分區(qū)散布到不同的Broker服務(wù)器上，zookeeper保存了broker、主題和分區(qū)的元數(shù)據(jù)信息。分區(qū)首體會處理來自客戶端的出產(chǎn)懇求，kafka分區(qū)首體會被分配到不同的broker服務(wù)器上，讓不同的broker服務(wù)器一起分管使命。
每一個broker都緩存了元數(shù)據(jù)信息，客戶端能夠從恣意一個broker獲取元數(shù)據(jù)信息并緩存起來，依據(jù)元數(shù)據(jù)信息知道要往哪里發(fā)送懇求。
2>kafka的顧客組訂閱同一個topic，會盡或許地使得每一個顧客分配到相同數(shù)量的分區(qū)，分?jǐn)傌?fù)載。
3>當(dāng)顧客參加或許退出顧客組的時分，還會觸發(fā)再均衡，為每一個顧客重新分配分區(qū)，分?jǐn)傌?fù)載。
kafka的負(fù)載均衡大部分是主動完成的，分區(qū)的創(chuàng)立也是kafka完成的，躲藏了許多細節(jié)，避免了繁瑣的裝備和人為忽略構(gòu)成的負(fù)載問題。
4>發(fā)送端由topic和key來決議音訊發(fā)往哪個分區(qū)，假如key為null，那么會運用輪詢算法將音訊均衡地發(fā)送到同一個topic的不同分區(qū)中。假如key不為null，那么會依據(jù)key的hashcode取模計算出要發(fā)往的分區(qū)。
rabbitmq：對負(fù)載均衡的支撐欠好。
1>音訊被投遞到哪個行列是由交換器和key決議的，交換器、路由鍵、行列都需求手動創(chuàng)立。
rabbitmq客戶端發(fā)送音訊要和broker樹立銜接，需求事先知道broker上有哪些交換器，有哪些行列。一般要聲明要發(fā)送的方針行列，假如沒有方針行列，會在broker上創(chuàng)立一個行列，假如有，就什么都不處理，接著往這個行列發(fā)送音訊。假設(shè)大部分深重使命的行列都創(chuàng)立在同一個broker上，那么這個broker的負(fù)載就會過大。（能夠在上線前預(yù)先創(chuàng)立行列，無需聲明要發(fā)送的行列，可是發(fā)送時不會嘗試創(chuàng)立行列，或許呈現(xiàn)找不到行列的問題，rabbitmq的備份交換器會把找不到行列的音訊保存到一個專門的行列中，以便以后查詢運用）
運用鏡像行列機制樹立rabbitmq集群能夠處理這個問題，構(gòu)成master-slave的架構(gòu)，master節(jié)點會均勻散布在不同的服務(wù)器上，讓每一臺服務(wù)器分?jǐn)傌?fù)載。slave節(jié)點僅僅負(fù)責(zé)轉(zhuǎn)發(fā)，在master失效時會選擇參加時刻最長的slave成為master。
當(dāng)新節(jié)點參加鏡像行列的時分，行列中的音訊不會同步到新的slave中，除非調(diào)用同步指令，可是調(diào)用指令后，行列會阻塞，不能在出產(chǎn)環(huán)境中調(diào)用同步指令。
2>當(dāng)rabbitmq行列具有多個顧客的時分，行列收到的音訊將以輪詢的分發(fā)辦法發(fā)送給顧客。每條音訊只會發(fā)送給訂閱列表里的一個顧客，不會重復(fù)。
這種辦法十分合適擴展，并且是專門為并發(fā)程序設(shè)計的。
假如某些顧客的使命比較深重，那么能夠設(shè)置basicQos約束信道上顧客能堅持的最大未承認(rèn)音訊的數(shù)量，在到達上限時，rabbitmq不再向這個顧客發(fā)送任何音訊。
3>關(guān)于rabbitmq而言，客戶端與集群樹立的TCP銜接不是與集群中一切的節(jié)點樹立銜接，而是挑選其間一個節(jié)點樹立銜接。
可是rabbitmq集群能夠借助HAProxy、LVS技能，或許在客戶端運用算法完成負(fù)載均衡，引進負(fù)載均衡之后，各個客戶端的銜接能夠分?jǐn)偟郊旱母鱾€節(jié)點之中。
客戶端均衡算法：
1)輪詢法。按次序回來下一個服務(wù)器的銜接地址。
2)加權(quán)輪詢法。給裝備高、負(fù)載低的機器裝備更高的權(quán)重，讓其處理更多的懇求；而裝備低、負(fù)載高的機器，給其分配較低的權(quán)重，降低其體系負(fù)載。
3)隨機法。隨機選取一個服務(wù)器的銜接地址。
4)加權(quán)隨機法。依照概率隨機選取銜接地址。
5)源地址哈希法。經(jīng)過哈希函數(shù)計算得到的一個數(shù)值，用該數(shù)值對服務(wù)器列表的巨細進行取模運算。
6)最小銜接數(shù)法。動態(tài)選擇當(dāng)時銜接數(shù)最少的一臺服務(wù)器的銜接地址。
zeromq：去中心化，不支撐負(fù)載均衡。自身僅僅一個多線程網(wǎng)絡(luò)庫。
rocketmq：支撐負(fù)載均衡。
一個broker一般是一個服務(wù)器節(jié)點，broker分為master和slave,master和slave存儲的數(shù)據(jù)相同，slave從master同步數(shù)據(jù)。
1>nameserver與每個集群成員堅持心跳，保存著Topic-Broker路由信息，同一個topic的行列會散布在不同的服務(wù)器上。
2>發(fā)送音訊經(jīng)過輪詢行列的辦法發(fā)送，每個行列接納均勻的音訊量。發(fā)送音訊指定topic、tags、keys，無法指定投遞到哪個行列（沒有意義，集群消費和播送消費跟音訊寄存在哪個行列沒有關(guān)系）。
tags選填，類似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過濾運用?，F(xiàn)在只支 持每個音訊設(shè)置一個 tag，所以也能夠類比為 Notify 的 MessageType 概念。
keys選填，代表這條音訊的事務(wù)關(guān)鍵詞，服務(wù)器會依據(jù) keys 創(chuàng)立哈希索引，設(shè)置后， 能夠在 Console 體系依據(jù) Topic、Keys 來查詢音訊，因為是哈希索引，請盡或許 確保 key 僅有，例如訂單號，產(chǎn)品 Id 等。
3>rocketmq的負(fù)載均衡戰(zhàn)略規(guī)定：Consumer數(shù)量應(yīng)該小于等于Queue數(shù)量，假如Consumer超越Queue數(shù)量，那么剩余的Consumer 將不能消費音訊。這一點和kafka是共同的，rocketmq會盡或許地為每一個Consumer分配相同數(shù)量的行列，分?jǐn)傌?fù)載。
activemq：支撐負(fù)載均衡。能夠依據(jù)zookeeper完成負(fù)載均衡。
七、集群辦法
Kafka：天然的‘Leader-Slave’無狀況集群，每臺服務(wù)器既是Master也是Slave。
分區(qū)領(lǐng)袖均勻地散布在不同的kafka服務(wù)器上，分區(qū)副本也均勻地散布在不同的kafka服務(wù)器上，所以每一臺kafka服務(wù)器既含有分區(qū)領(lǐng)袖，一起又含有分區(qū)副本，每一臺kafka服務(wù)器是某一臺kafka服務(wù)器的Slave，一起也是某一臺kafka服務(wù)器的leader。
kafka的集群依賴于zookeeper，zookeeper支撐熱擴展，一切的broker、顧客、分區(qū)都能夠動態(tài)參加移除，而無需封閉服務(wù)，與不依托zookeeper集群的mq比較，這是最大的優(yōu)勢。
rabbitmq：支撐簡略集群，'仿制'辦法，對高檔集群辦法支撐欠好。
rabbitmq的每一個節(jié)點，不管是單一節(jié)點體系或許是集群中的一部分，要么是內(nèi)存節(jié)點，要么是磁盤節(jié)點，集群中至少要有一個是磁盤節(jié)點。
在rabbitmq集群中創(chuàng)立行列，集群只會在單個節(jié)點創(chuàng)立行列進程和完好的行列信息（元數(shù)據(jù)、狀況、內(nèi)容），而不是在一切節(jié)點上創(chuàng)立。
引進鏡像行列，能夠避免單點故障，確保服務(wù)的可用性，可是需求人為地為某些重要的行列裝備鏡像。
zeromq：去中心化，不支撐集群。
rocketmq：常用 多對'Master-Slave' 辦法，開源版別需手動切換Slave變成Master
Name Server是一個簡直無狀況節(jié)點，可集群布置，節(jié)點之間無任何信息同步。
Broker布置相對雜亂，Broker分為Master與Slave，一個Master能夠?qū)?yīng)多個Slave，可是一個Slave只能對應(yīng)一個Master，Master與Slave的對應(yīng)關(guān)系經(jīng)過指定相同的BrokerName，不同的BrokerId來界說，BrokerId為0表示Master，非0表示Slave。Master也能夠布置多個。每個Broker與Name Server集群中的一切節(jié)點樹立長銜接，守時注冊Topic信息到一切Name Server。
Producer與Name Server集群中的其間一個節(jié)點（隨機選擇）樹立長銜接，守時從Name Server取Topic路由信息，并向供給Topic服務(wù)的Master樹立長銜接，且守時向Master發(fā)送心跳。Producer徹底無狀況，可集群布置。
Consumer與Name Server集群中的其間一個節(jié)點（隨機選擇）樹立長銜接，守時從Name Server取Topic路由信息，并向供給Topic服務(wù)的Master、Slave樹立長銜接，且守時向Master、Slave發(fā)送心跳。Consumer既能夠從Master訂閱音訊，也能夠從Slave訂閱音訊，訂閱規(guī)則由Broker裝備決議。
客戶端先找到NameServer, 然后經(jīng)過NameServer再找到 Broker。
一個topic有多個行列，這些行列會均勻地散布在不同的broker服務(wù)器上。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：高（主從）
十、音訊重復(fù)
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：依據(jù)topic以及依照topic進行正則匹配的發(fā)布訂閱辦法。
【發(fā)送】
發(fā)送端由topic和key來決議音訊發(fā)往哪個分區(qū)，假如key為null，那么會運用輪詢算法將音訊均衡地發(fā)送到同一個topic的不同分區(qū)中。假如key不為null，那么會依據(jù)key的hashcode取模計算出要發(fā)往的分區(qū)。
【接納】
1>consumer向群組協(xié)調(diào)器broker發(fā)送心跳來維持他們和群組的從屬關(guān)系以及他們對分區(qū)的一切權(quán)關(guān)系，一切權(quán)關(guān)系一旦被分配就不會改變除非產(chǎn)生再均衡(比方有一個consumer參加或許脫離consumer group)，consumer只會從對應(yīng)的分區(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)立或許現(xiàn)已被創(chuàng)立，行列是根本存儲單元。
由exchange和key決議音訊存儲在哪個行列。
direct>發(fā)送到和bindingKey徹底匹配的行列。
topic>路由key是含有"."的字符串，會發(fā)送到含有“*”、“#”進行含糊匹配的bingKey對應(yīng)的行列。
fanout>與key無關(guān)，會發(fā)送到一切和exchange綁定的行列
headers>與key無關(guān)，音訊內(nèi)容的headers特點（一個鍵值對）和綁定鍵值對徹底匹配時，會發(fā)送到此行列。此辦法功能低一般不必
【接納】
rabbitmq的行列是根本存儲單元，不再被分區(qū)或許分片，關(guān)于咱們現(xiàn)已創(chuàng)立了的行列，消費端要指定從哪一個行列接納音訊。
當(dāng)rabbitmq行列具有多個顧客的時分，行列收到的音訊將以輪詢的分發(fā)辦法發(fā)送給顧客。每條音訊只會發(fā)送給訂閱列表里的一個顧客，不會重復(fù)。
這種辦法十分合適擴展，并且是專門為并發(fā)程序設(shè)計的。
假如某些顧客的使命比較深重，那么能夠設(shè)置basicQos約束信道上顧客能堅持的最大未承認(rèn)音訊的數(shù)量，在到達上限時，rabbitmq不再向這個顧客發(fā)送任何音訊。
zeromq：點對點(p2p)
rocketmq：依據(jù)topic/messageTag以及依照音訊類型、特點進行正則匹配的發(fā)布訂閱辦法
【發(fā)送】
發(fā)送音訊經(jīng)過輪詢行列的辦法發(fā)送，每個行列接納均勻的音訊量。發(fā)送音訊指定topic、tags、keys，無法指定投遞到哪個行列（沒有意義，集群消費和播送消費跟音訊寄存在哪個行列沒有關(guān)系）。
tags選填，類似于 Gmail 為每封郵件設(shè)置的標(biāo)簽，方便服務(wù)器過濾運用?，F(xiàn)在只支 持每個音訊設(shè)置一個 tag，所以也能夠類比為 Notify 的 MessageType 概念。
keys選填，代表這條音訊的事務(wù)關(guān)鍵詞，服務(wù)器會依據(jù) keys 創(chuàng)立哈希索引，設(shè)置后， 能夠在 Console 體系依據(jù) Topic、Keys 來查詢音訊，因為是哈希索引，請盡或許 確保 key 僅有，例如訂單號，產(chǎn)品 Id 等。
【接納】
1>播送消費。一條音訊被多個Consumer消費，即便Consumer屬于同一個ConsumerGroup，音訊也會被ConsumerGroup中的每個Consumer都消費一次。
2>集群消費。一個 Consumer Group中的Consumer實例均勻分?jǐn)傁M音訊。例如某個Topic有 9 條音訊，其間一個Consumer Group有3個實例，那么每個實例只消費其間的 3 條音訊。即每一個行列都把音訊輪番分發(fā)給每個consumer。
activemq：點對點(p2p)、播送（發(fā)布-訂閱）
點對點辦法，每個音訊只要1個顧客；
發(fā)布/訂閱辦法，每個音訊能夠有多個顧客。
【發(fā)送】
點對點辦法：先要指定一個行列，這個行列會被創(chuàng)立或許現(xiàn)已被創(chuàng)立。
發(fā)布/訂閱辦法：先要指定一個topic，這個topic會被創(chuàng)立或許現(xiàn)已被創(chuàng)立。
【接納】
點對點辦法：關(guān)于現(xiàn)已創(chuàng)立了的行列，消費端要指定從哪一個行列接納音訊。
發(fā)布/訂閱辦法：關(guān)于現(xiàn)已創(chuàng)立了的topic，消費端要指定訂閱哪一個topic的音訊。
十三、次序音訊
Kafka：支撐。
設(shè)置出產(chǎn)者的max.in.flight.requests.per.connection為1，能夠確保音訊是依照發(fā)送次序?qū)懭敕?wù)器的，即便產(chǎn)生了重試。
kafka確保同一個分區(qū)里的音訊是有序的，可是這種有序分兩種狀況
1>key為null，音訊逐一被寫入不同主機的分區(qū)中，可是關(guān)于每個分區(qū)依然是有序的
2>key不為null , 音訊被寫入到同一個分區(qū)，這個分區(qū)的音訊都是有序。
rabbitmq：不支撐
zeromq：不支撐
rocketmq：支撐
activemq：不支撐
十四、音訊承認(rèn)
Kafka：支撐。
1>發(fā)送方承認(rèn)機制
ack=0，不管音訊是否成功寫入分區(qū)
ack=1，音訊成功寫入領(lǐng)袖分區(qū)后，回來成功
ack=all，音訊成功寫入一切分區(qū)后，回來成功。
2>接納方承認(rèn)機制
主動或許手動提交分區(qū)偏移量，早期版別的kafka偏移量是提交給Zookeeper的，這樣使得zookeeper的壓力比較大，更新版別的kafka的偏移量是提交給kafka服務(wù)器的，不再依賴于zookeeper群組，集群的功能愈加穩(wěn)定。
rabbitmq：支撐。
1>發(fā)送方承認(rèn)機制，音訊被投遞到一切匹配的行列后，回來成功。假如音訊和行列是可耐久化的，那么在寫入磁盤后，回來成功。支撐批量承認(rèn)和異步承認(rèn)。
2>接納方承認(rèn)機制，設(shè)置autoAck為false，需求顯式承認(rèn)，設(shè)置autoAck為true，主動承認(rèn)。
當(dāng)autoAck為false的時分，rabbitmq行列會分成兩部分，一部分是等候投遞給consumer的音訊，一部分是現(xiàn)已投遞可是沒收到承認(rèn)的音訊。假如一向沒有收到承認(rèn)信號，并且consumer現(xiàn)已斷開銜接，rabbitmq會安排這個音訊重新進入行列，投遞給原來的顧客或許下一個顧客。
未承認(rèn)的音訊不會有過期時刻，假如一向沒有承認(rèn)，并且沒有斷開銜接，rabbitmq會一向等候，rabbitmq允許一條音訊處理的時刻能夠很久很久。
zeromq：支撐。
rocketmq：支撐。
activemq：支撐。
十五、音訊回溯
Kafka：支撐指定分區(qū)offset方位的回溯。rabbitmq：不支撐 zeromq：不支撐 rocketmq：支撐指守時刻點的回溯。activemq：不支撐
十六、音訊重試
Kafka：不支撐，可是能夠完成。
kafka支撐指定分區(qū)offset方位的回溯，能夠完成音訊重試。
rabbitmq：不支撐，可是能夠利用音訊承認(rèn)機制完成。
rabbitmq接納方承認(rèn)機制，設(shè)置autoAck為false。
當(dāng)autoAck為false的時分，rabbitmq行列會分成兩部分，一部分是等候投遞給consumer的音訊，一部分是現(xiàn)已投遞可是沒收到承認(rèn)的音訊。假如一向沒有收到承認(rèn)信號，并且consumer現(xiàn)已斷開銜接，rabbitmq會安排這個音訊重新進入行列，投遞給原來的顧客或許下一個顧客。
zeromq：不支撐，
rocketmq：支撐。
音訊消費失利的大部分場景下，立即重試99%都會失利，所以rocketmq的戰(zhàn)略是在消費失利時守時重試，每次時刻距離相同。
1>發(fā)送端的 send 辦法自身支撐內(nèi)部重試，重試邏輯如下：
a)至多重試3次；
b)假如發(fā)送失利，則輪轉(zhuǎn)到下一個broker；
c)這個辦法的總耗時不超越sendMsgTimeout 設(shè)置的值，默認(rèn) 10s，超越時刻不在重試。
2>接納端。
Consumer 消費音訊失利后，要供給一種重試機制，令音訊再消費一次。Consumer 消費音訊失利一般能夠分為以下兩種狀況：
- 因為音訊自身的原因，例如反序列化失利，音訊數(shù)據(jù)自身無法處理（例如話費充值，當(dāng)時音訊的手機號被
注銷，無法充值）等。守時重試機制，比方過 10s 秒后再重試。
- 因為依賴的下游應(yīng)用服務(wù)不可用，例如 db 銜接不可用，外體系網(wǎng)絡(luò)不可達等。
即便越過當(dāng)時失利的音訊，消費其他音訊相同也會報錯。這種狀況能夠 sleep 30s，再消費下一條音訊，減輕 Broker 重試音訊的壓力。
activemq：不支撐
十七、并發(fā)度
Kafka：高
一個線程一個顧客，kafka約束顧客的個數(shù)要小于等于分區(qū)數(shù)，假如要進步并行度，能夠在顧客中再敞開多線程，或許添加consumer實例數(shù)量。
rabbitmq：極高
自身是用Erlang言語寫的，并發(fā)功能高。
可在顧客中敞開多線程，最常用的做法是一個channel對應(yīng)一個顧客，每一個線程操縱一個channel，多個線程復(fù)用connection的tcp銜接，削減功能開銷。
當(dāng)rabbitmq行列具有多個顧客的時分，行列收到的音訊將以輪詢的分發(fā)辦法發(fā)送給顧客。每條音訊只會發(fā)送給訂閱列表里的一個顧客，不會重復(fù)。
這種辦法十分合適擴展，并且是專門為并發(fā)程序設(shè)計的。
假如某些顧客的使命比較深重，那么能夠設(shè)置basicQos約束信道上顧客能堅持的最大未承認(rèn)音訊的數(shù)量，在到達上限時，rabbitmq不再向這個顧客發(fā)送任何音訊。
zeromq：高
rocketmq：高
1>rocketmq約束顧客的個數(shù)少于等于行列數(shù)，可是能夠在顧客中再敞開多線程，這一點和kafka是共同的，進步并行度的辦法相同。
修正消費并行度辦法
a) 同一個 ConsumerGroup 下，經(jīng)過添加 Consumer 實例數(shù)量來進步并行度，超越訂閱行列數(shù)的 Consumer實例無效。
b) 進步單個 Consumer 的消費并行線程，經(jīng)過修正參數(shù)consumeThreadMin、consumeThreadMax
2>同一個網(wǎng)絡(luò)銜接connection，客戶端多個線程能夠一起發(fā)送懇求，銜接會被復(fù)用，削減功能開銷。
activemq：高
單個ActiveMQ的接納和消費音訊的速度在1萬筆/秒（耐久化 一般為1-2萬， 非耐久化 2 萬以上），在出產(chǎn)環(huán)境中布置10個Activemq就能到達10萬筆/秒以上的功能，布置越多的activemq broker 在MQ上latency也就越低，體系吞吐量也就越高。