RabbitMQ和Kafka如何選擇

小編給大家分享一下RabbitMQ和Kafka如何選擇，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

RabbitMQ架構(gòu)

RabbitMQ是一個分布式系統(tǒng)，這里面有幾個抽象概念。

• broker：每個節(jié)點運行的服務程序，功能為維護該節(jié)點的隊列的增刪以及轉(zhuǎn)發(fā)隊列操作請求。

• master queue：每個隊列都分為一個主隊列和若干個鏡像隊列。

• mirror queue：鏡像隊列，作為master queue的備份。在master queue所在節(jié)點掛掉之后，系統(tǒng)把mirror queue提升為master queue，負責處理客戶端隊列操作請求。注意，mirror queue只做鏡像，設計目的不是為了承擔客戶端讀寫壓力。

如上圖所示，集群中有兩個節(jié)點，每個節(jié)點上有一個broker，每個broker負責本機上隊列的維護，并且borker之間可以互相通信。

集群中有兩個隊列A和B，每個隊列都分為master queue和mirror queue（備份）。那么隊列上的生產(chǎn)消費怎么實現(xiàn)的呢？

隊列消費

如上圖有兩個consumer消費隊列A，這兩個consumer連在了集群的不同機器上。RabbitMQ集群中的任何一個節(jié)點都擁有集群上所有隊列的元信息，所以連接到集群中的任何一個節(jié)點都可以，主要區(qū)別在于有的consumer連在master queue所在節(jié)點，有的連在非master queue節(jié)點上。

因為mirror queue要和master queue保持一致，故需要同步機制，正因為一致性的限制，導致所有的讀寫操作都必須都操作在master queue上（想想，為啥讀也要從master queue中讀？和數(shù)據(jù)庫讀寫分離是不一樣的。），

然后由master節(jié)點同步操作到mirror queue所在的節(jié)點。

即使consumer連接到了非master queue節(jié)點，該consumer的操作也會被路由到master queue所在的節(jié)點上，這樣才能進行消費。

隊列生產(chǎn)

原理和消費一樣，如果連接到非 master queue 節(jié)點，則路由過去。

所以，到這里小伙伴們就可以看到 RabbitMQ的不足：由于master queue單節(jié)點，導致性能瓶頸，吞吐量受限。雖然為了提高性能，內(nèi)部使用了Erlang這個語言實現(xiàn)，但是終究擺脫不了架構(gòu)設計上的致命缺陷。

Kafka

說實話，Kafka我覺得就是看到了RabbitMQ這個缺陷才設計出的一個改進版，改進的點就是：把一個隊列的單一master變成多個master，即一臺機器扛不住qps，那么我就用多臺機器扛qps，把一個隊列的流量均勻分散在多臺機器上不就可以了么？

注意，多個master之間的數(shù)據(jù)沒有交集，即一條消息要么發(fā)送到這個master queue，要么發(fā)送到另外一個master queue。

這里面的每個master queue 在Kafka中叫做Partition，即一個分片。一個隊列有多個主分片，每個主分片又有若干副分片做備份，同步機制類似于RabbitMQ。

如上圖，我們省略了不同的queue，假設集群上只有一個queue（Kafka中叫Topic）。每個生產(chǎn)者隨機把消息發(fā)送到主分片上，之后主分片再同步給副分片。

隊列讀取的時候虛擬出一個Group的概念，一個Topic內(nèi)部的消息，只會路由到同Group內(nèi)的一個consumer上，同一個Group中的consumer消費的消息是不一樣的；Group之間共享一個Topic，看起來就是一個隊列的多個拷貝。

所以，為了達到多個Group共享一個Topic數(shù)據(jù)，Kafka并不會像RabbitMQ那樣消息消費完畢立馬刪除，而是必須在后臺配置保存日期，即只保存最近一段時間的消息，超過這個時間的消息就會從磁盤刪除，這樣就保證了在一個時間段內(nèi)，Topic數(shù)據(jù)對所有Group可見（這個特性使得Kafka非常適合做一個公司的數(shù)據(jù)總線）。

隊列讀同樣是讀主分片，并且為了優(yōu)化性能，消費者與主分片有一一的對應關(guān)系，如果消費者數(shù)目大于分片數(shù)，則存在某些消費者得不到消息。

由此可見，Kafka絕對是為了高吞吐量設計的，比如設置分片數(shù)為100，那么就有100臺機器去扛一個Topic的流量，當然比RabbitMQ的單機性能好。

本文只做了Kafka和RabbitMQ的對比，但是開源隊列豈止這兩個，ZeroMQ，RocketMQ，JMQ等等，時間有限也就沒有細看，故不在本文比較范圍之內(nèi)。

所以，別再被這些五花八門的隊列迷惑了，從架構(gòu)上找出關(guān)鍵差別，并結(jié)合自己的實際需求（比如本文就只單單從吞吐量一個需求來考察）輕輕松松搞定選型。

最后總結(jié)如下：

• 吞吐量較低：Kafka和RabbitMQ都可以。

• 吞吐量高：Kafka。

以上是“RabbitMQ和Kafka如何選擇”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！