平時(shí)經(jīng)常會(huì)看到很多人寫文章分析Kafka、RabbitMQ、RocketMQ等各種MQ之間的性能比較，功能比較，但是實(shí)際上從MQ消息隊(duì)列的門派上來說，這些MQ其實(shí)是分屬不同的門派的。

那么這不同的門派之間，到底有什么區(qū)別呢？

（1）流派1：有Broker的暴力路由

這個(gè)流派最典型的就是Kafka了，Kafka實(shí)際上為了提升性能，簡化了MQ功能模型，僅僅提供了一些最基礎(chǔ)的MQ相關(guān)的功能，但是大幅度優(yōu)化和提升了吞吐量。

首先，這個(gè)流派一定是有一個(gè)Broker角色的，也就是說，Kafka需要部署一套服務(wù)器集群，每臺機(jī)器上都有一個(gè)Kafka Broker進(jìn)程，這個(gè)進(jìn)程就負(fù)責(zé)接收請求，存儲數(shù)據(jù)，發(fā)送數(shù)據(jù)。

Kafka的生產(chǎn)消費(fèi)模型做的相對是比較暴力簡單的，就是簡單的數(shù)據(jù)流模型。

簡單來說，他有一個(gè)概念，叫做“Topic”，你可以往這個(gè)“Topic”里寫數(shù)據(jù)，然后讓別人從這里來消費(fèi)。

這個(gè)Topic可以劃分為多個(gè)Partition，每個(gè)Partition放一臺機(jī)器上，存儲一部分?jǐn)?shù)據(jù)。

在寫消息到Topic的時(shí)候，會(huì)自動(dòng)把你這個(gè)消息給分發(fā)到某一個(gè)Partition上去。

然后消費(fèi)消息的時(shí)候，有一個(gè)Consumer Group的概念，你部署在多臺機(jī)器上的Consumer可以組成一個(gè)Group，一個(gè)Partition只能給一個(gè)Consumer消費(fèi)，一個(gè)Cosumer可以消費(fèi)多個(gè)Partition，這是最最核心的一點(diǎn)。

通過這個(gè)模型，保證一個(gè)Topic里的每條消息，只會(huì)交給Consumer Group里的一個(gè)Consumer來消費(fèi)，形成了一個(gè)Queue（隊(duì)列）的效果。

假如你想要有一個(gè)Queue的效果，也就是希望不停的往Queue里寫數(shù)據(jù)，然后多個(gè)消費(fèi)者消費(fèi)，每條消息就只能給一個(gè)消費(fèi)者，那么通過Kafka來實(shí)現(xiàn)，其實(shí)就是生產(chǎn)者寫多個(gè)Partition，每個(gè)Partition只能給Consumer Group中的一個(gè)Consumer來消費(fèi)。如下圖所示：

如果要實(shí)現(xiàn)Publish/Subscribe的模型呢？就是說生產(chǎn)者發(fā)送的每條消息，都要讓所有消費(fèi)都消費(fèi)到，怎么實(shí)現(xiàn)？

那就讓每個(gè)消費(fèi)者都是一個(gè)獨(dú)立的消費(fèi)組，這樣每條消息都會(huì)發(fā)送給所有的消費(fèi)組，每個(gè)消費(fèi)組里那唯一的一個(gè)消費(fèi)者一定會(huì)消費(fèi)到所有的消息。

但是除此之外，Kafka就沒有任何其他的消費(fèi)功能了，就是如此簡單，所以屬于一種比較暴力直接的流派。

它就是簡單的消費(fèi)模型，實(shí)現(xiàn)最基礎(chǔ)的Queue和Pub/Sub兩種消費(fèi)模型，但是內(nèi)核中大幅度優(yōu)化和提升了性能以及吞吐量。

所以Kafka天生適合的場景，就是大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)數(shù)據(jù)計(jì)算的場景。

因?yàn)樵诖髷?shù)據(jù)的場景下，通常是弱業(yè)務(wù)的場景，沒有太多復(fù)雜的業(yè)務(wù)系統(tǒng)交互，而主要是大量的數(shù)據(jù)流入Kafka，然后進(jìn)行實(shí)時(shí)計(jì)算。

所以就是需要簡單的消費(fèi)模型，但是必須在內(nèi)核中對吞吐量和性能進(jìn)行大幅度的優(yōu)化。

因此Kafka技術(shù)通常是在大數(shù)據(jù)的實(shí)時(shí)數(shù)據(jù)計(jì)算領(lǐng)域中使用的，比如說每秒處理幾十萬條消息，甚至每秒處理上百萬條消息。

（2）流派2：有Broker的復(fù)雜路由

第二個(gè)流派，就是RabbitMQ為代表的流派，他強(qiáng)調(diào)的不是說如何提升性能和吞吐量，關(guān)注的是說要提供非常強(qiáng)大、復(fù)雜而且完善的消息路由功能。

所以對于RabbitMQ而言，他就不是那么簡單的Topic-Partition的消費(fèi)模型了。

在RabbitMQ中引入了一個(gè)非常核心的概念，叫做Exchange，這個(gè)Exchange就是負(fù)責(zé)根據(jù)復(fù)雜的業(yè)務(wù)規(guī)則把消息路由到內(nèi)部的不同的Queue里去。

舉個(gè)例子，如果要實(shí)現(xiàn)最簡單的隊(duì)列功能，就是讓exchange往一個(gè)queue里寫數(shù)據(jù)，然后多個(gè)消費(fèi)者來消費(fèi)這個(gè)queue里的數(shù)據(jù)，每條消息只能給一個(gè)消費(fèi)者，那么可以是類似下面的方式。

如果想要實(shí)現(xiàn)Pub/Sub的模型，就是一條消息要被所有的消費(fèi)者給消費(fèi)到，那么就可以讓每個(gè)消費(fèi)者都有一個(gè)自己的Queue，然后綁定到一個(gè)Exchange上去。

接著，這個(gè)Exchange就設(shè)定把消息路由給所有的Queue即可，如下面這樣。

此時(shí)Exchange可以把每條消息都路由給所有的Queue，每個(gè)Consumer都可以從自己的Queue里拿到所有的消息。

RabbitMQ這種流派，其實(shí)最核心的是，基于Exchange這個(gè)概念，他可以做很多復(fù)雜的事情。

比如：如果你想要某個(gè)Consumer只能消費(fèi)到某一類數(shù)據(jù)，那么Exchange可以把消息里比如帶“XXX”前綴的消息路由給某個(gè)Queue?；蛘吣憧梢韵薅硞€(gè)Consumer就只能消費(fèi)某一部分?jǐn)?shù)據(jù)?？傊谶@里你可以做很多的限制，設(shè)置復(fù)雜的路由規(guī)則。

但是也正是因?yàn)橐肓诉@種復(fù)雜的消費(fèi)模型，支持復(fù)雜的路由功能，導(dǎo)致RabbitMQ在內(nèi)核以及架構(gòu)設(shè)計(jì)上沒法像Kafka做的那么的輕量級、高性能、可擴(kuò)展、高吞吐，所以RabbitMQ在吞吐量上要比Kafka低一個(gè)數(shù)量級。

所以這種流派的MQ，往往適合用在Java業(yè)務(wù)系統(tǒng)中，不同的業(yè)務(wù)系統(tǒng)需要進(jìn)行復(fù)雜的消息路由。

比如說業(yè)務(wù)系統(tǒng)A發(fā)送了10條消息，其中3條消息是給業(yè)務(wù)系統(tǒng)B的，7條消息是給業(yè)務(wù)系統(tǒng)C的，要實(shí)現(xiàn)這種復(fù)雜的路由模型，就必須依靠RabbitMQ來實(shí)現(xiàn)。

當(dāng)然，對于這種業(yè)務(wù)系統(tǒng)之間的消息流轉(zhuǎn)而言，可能不需要那么高的吞吐量，可能每秒業(yè)務(wù)系統(tǒng)之間也就轉(zhuǎn)發(fā)幾十條或者幾百條消息，那么就完全適合采用RabbitMQ來實(shí)現(xiàn)。

（3）流派3：無Broker的通信流派

ZeroMQ代表的是第三種MQ。說白了，他是不需要在服務(wù)器上部署的，就是一個(gè)客戶端的庫而已。

也就是說，他主要是封裝了底層的Socket網(wǎng)絡(luò)通訊，然后一個(gè)系統(tǒng)要發(fā)送一條消息給另外一個(gè)消息消費(fèi) 。

通過ZeroMQ，本質(zhì)就是底層ZeroMQ發(fā)送一條消息到另外一個(gè)系統(tǒng)上去。

所以ZeroMQ是去中心化的，不需要跟Kafka、RabbitMQ一樣在服務(wù)器上部署的。

他主要是用來進(jìn)行業(yè)務(wù)系統(tǒng)之間的網(wǎng)絡(luò)通信的，有點(diǎn)類似于比如你是一個(gè)分布式系統(tǒng)架構(gòu)，那么此時(shí)分布式架構(gòu)中的各個(gè)子系統(tǒng)互相之間要通信，你是基于Dubbo RPC？還是Spring Cloud HTTP？

可能上述兩種你都不想要，就是要基于原始的Socket進(jìn)行網(wǎng)絡(luò)通信，簡單的收發(fā)消息而已。

此時(shí)就可以使用ZeroMQ作為分布式系統(tǒng)之間的消息通信，如下面那樣。

（4）總結(jié)

其實(shí)現(xiàn)在基本上MQ主要就是這三個(gè)流派，很多小眾的MQ一般很少有人會(huì)用。

而且用MQ的場景主要就是兩大類：

1. 業(yè)務(wù)系統(tǒng)之間異步通信

2. 大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)數(shù)據(jù)計(jì)算

   
   

所以一般業(yè)務(wù)系統(tǒng)之間通信就是會(huì)采用RabbitMQ/RocketMQ，需要復(fù)雜的消息路由功能的支撐。

大數(shù)據(jù)的實(shí)時(shí)計(jì)算場景會(huì)采用Kafka，需要簡單的消費(fèi)模型，但是超高的吞吐量。

至于ZeroMQ，一般來說，少數(shù)分布式系統(tǒng)中子系統(tǒng)之間的分布式通信時(shí)會(huì)采用，作為輕量級的異步化的通信組件。