來(lái)源：cnblogs.com/haolujun/p/9632835.html
前言
開(kāi)源社區(qū)有好多優(yōu)秀的隊(duì)列中間件，比如RabbitMQ和Kafka，每個(gè)隊(duì)列都貌似有其特性，在進(jìn)行工程選擇時(shí)，往往眼花繚亂，不知所措。對(duì)于RabbitMQ和Kafka，到底應(yīng)該選哪個(gè)？
RabbitMQ架構(gòu)
RabbitMQ是一個(gè)分布式系統(tǒng)，這里面有幾個(gè)抽象概念。
broker：每個(gè)節(jié)點(diǎn)運(yùn)行的服務(wù)程序，功能為維護(hù)該節(jié)點(diǎn)的隊(duì)列的增刪以及轉(zhuǎn)發(fā)隊(duì)列操作請(qǐng)求。
master queue：每個(gè)隊(duì)列都分為一個(gè)主隊(duì)列和若干個(gè)鏡像隊(duì)列。
mirror queue：鏡像隊(duì)列，作為master queue的備份。在master queue所在節(jié)點(diǎn)掛掉之后，系統(tǒng)把mirror queue提升為master queue，負(fù)責(zé)處理客戶端隊(duì)列操作請(qǐng)求。注意，mirror queue只做鏡像，設(shè)計(jì)目的不是為了承擔(dān)客戶端讀寫壓力。
如上圖所示，集群中有兩個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)上有一個(gè)broker，每個(gè)broker負(fù)責(zé)本機(jī)上隊(duì)列的維護(hù)，并且borker之間可以互相通信。集群中有兩個(gè)隊(duì)列A和B，每個(gè)隊(duì)列都分為master queue和mirror queue（備份）。那么隊(duì)列上的生產(chǎn)消費(fèi)怎么實(shí)現(xiàn)的呢？
隊(duì)列消費(fèi)
如上圖有兩個(gè)consumer消費(fèi)隊(duì)列A，這兩個(gè)consumer連在了集群的不同機(jī)器上。RabbitMQ集群中的任何一個(gè)節(jié)點(diǎn)都擁有集群上所有隊(duì)列的元信息，所以連接到集群中的任何一個(gè)節(jié)點(diǎn)都可以，主要區(qū)別在于有的consumer連在master queue所在節(jié)點(diǎn)，有的連在非master queue節(jié)點(diǎn)上。
因?yàn)閙irror queue要和master queue保持一致，故需要同步機(jī)制，正因?yàn)橐恢滦缘南拗疲瑢?dǎo)致所有的讀寫操作都必須都操作在master queue上（想想，為啥讀也要從master queue中讀？和數(shù)據(jù)庫(kù)讀寫分離是不一樣的。），然后由master節(jié)點(diǎn)同步操作到mirror queue所在的節(jié)點(diǎn)。即使consumer連接到了非master queue節(jié)點(diǎn)，該consumer的操作也會(huì)被路由到master queue所在的節(jié)點(diǎn)上，這樣才能進(jìn)行消費(fèi)。
隊(duì)列生產(chǎn)
原理和消費(fèi)一樣，如果連接到非 master queue 節(jié)點(diǎn)，則路由過(guò)去。
所以，到這里小伙伴們就可以看到 RabbitMQ的不足：由于master queue單節(jié)點(diǎn)，導(dǎo)致性能瓶頸，吞吐量受限。雖然為了提高性能，內(nèi)部使用了Erlang這個(gè)語(yǔ)言實(shí)現(xiàn)，但是終究擺脫不了架構(gòu)設(shè)計(jì)上的致命缺陷。
Kafka
說(shuō)實(shí)話，Kafka我覺(jué)得就是看到了RabbitMQ這個(gè)缺陷才設(shè)計(jì)出的一個(gè)改進(jìn)版，改進(jìn)的點(diǎn)就是：把一個(gè)隊(duì)列的單一master變成多個(gè)master，即一臺(tái)機(jī)器扛不住qps，那么我就用多臺(tái)機(jī)器扛qps，把一個(gè)隊(duì)列的流量均勻分散在多臺(tái)機(jī)器上不就可以了么？注意，多個(gè)master之間的數(shù)據(jù)沒(méi)有交集，即一條消息要么發(fā)送到這個(gè)master queue，要么發(fā)送到另外一個(gè)master queue。
另外，關(guān)注互聯(lián)網(wǎng)架構(gòu)師公眾號(hào)，回復(fù)“面試”，送你一份面試題寶典！
這里面的每個(gè)master queue 在Kafka中叫做Partition，即一個(gè)分片。一個(gè)隊(duì)列有多個(gè)主分片，每個(gè)主分片又有若干副分片做備份，同步機(jī)制類似于RabbitMQ。
如上圖，我們省略了不同的queue，假設(shè)集群上只有一個(gè)queue（Kafka中叫Topic）。每個(gè)生產(chǎn)者隨機(jī)把消息發(fā)送到主分片上，之后主分片再同步給副分片。
隊(duì)列讀取的時(shí)候虛擬出一個(gè)Group的概念，一個(gè)Topic內(nèi)部的消息，只會(huì)路由到同Group內(nèi)的一個(gè)consumer上，同一個(gè)Group中的consumer消費(fèi)的消息是不一樣的；Group之間共享一個(gè)Topic，看起來(lái)就是一個(gè)隊(duì)列的多個(gè)拷貝。
所以，為了達(dá)到多個(gè)Group共享一個(gè)Topic數(shù)據(jù)，Kafka并不會(huì)像RabbitMQ那樣消息消費(fèi)完畢立馬刪除，而是必須在后臺(tái)配置保存日期，即只保存最近一段時(shí)間的消息，超過(guò)這個(gè)時(shí)間的消息就會(huì)從磁盤刪除，這樣就保證了在一個(gè)時(shí)間段內(nèi)，Topic數(shù)據(jù)對(duì)所有Group可見(jiàn)（這個(gè)特性使得Kafka非常適合做一個(gè)公司的數(shù)據(jù)總線）。
隊(duì)列讀同樣是讀主分片，并且為了優(yōu)化性能，消費(fèi)者與主分片有一一的對(duì)應(yīng)關(guān)系，如果消費(fèi)者數(shù)目大于分片數(shù)，則存在某些消費(fèi)者得不到消息。
由此可見(jiàn)，Kafka絕對(duì)是為了高吞吐量設(shè)計(jì)的，比如設(shè)置分片數(shù)為100，那么就有100臺(tái)機(jī)器去扛一個(gè)Topic的流量，當(dāng)然比RabbitMQ的單機(jī)性能好。
總結(jié)
本文只做了Kafka和RabbitMQ的對(duì)比，但是開(kāi)源隊(duì)列豈止這兩個(gè)，ZeroMQ，RocketMQ，JMQ等等，時(shí)間有限也就沒(méi)有細(xì)看，故不在本文比較范圍之內(nèi)。
所以，別再被這些五花八門的隊(duì)列迷惑了，從架構(gòu)上找出關(guān)鍵差別，并結(jié)合自己的實(shí)際需求（比如本文就只單單從吞吐量一個(gè)需求來(lái)考察）輕輕松松搞定選型。最后總結(jié)如下：
吞吐量較低：Kafka和RabbitMQ都可以。
吞吐量高：Kafka。
本文內(nèi)容參考自RabbitMQ和KafKa官方文檔，所以真要搞懂一個(gè)中間件的原理最好去看官方文檔，文檔里面有詳細(xì)的設(shè)計(jì)方案，我們可以自己進(jìn)行設(shè)計(jì)方案的對(duì)比，從而找出符合自己實(shí)際情況的中間件。