消息隊(duì)列中間件重要嗎？面試必問(wèn)問(wèn)題之一，你說(shuō)重不重要。我有時(shí)會(huì)問(wèn)同事，為啥你用 RabbitMQ，不用 Kafka，或者 RocketMQ 呢，他給我的回答 “因?yàn)楣居玫木褪沁@個(gè)，大家都這么用”，如果你去面試，直接就被 Pass，今天這篇文章，告訴你如何回答。

這篇文章，我重點(diǎn)突出消息隊(duì)列選型，弱化每種隊(duì)列內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，精華提煉，可讀性更強(qiáng)！

常用的消息隊(duì)列主要這 4 種，分別為 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ，主要介紹前三，不BB，上思維導(dǎo)圖！

消息隊(duì)列基礎(chǔ)

什么是消息隊(duì)列？

消息隊(duì)列是在消息的傳輸過(guò)程中保存消息的容器，用于接收消息并以文件的方式存儲(chǔ)，一個(gè)消息隊(duì)列可以被一個(gè)也可以被多個(gè)消費(fèi)者消費(fèi)，包含以下 3 元素：

Producer：消息生產(chǎn)者，負(fù)責(zé)產(chǎn)生和發(fā)送消息到 Broker；

Broker：消息處理中心，負(fù)責(zé)消息存儲(chǔ)、確認(rèn)、重試等，一般其中會(huì)包含多個(gè) Queue；

Consumer：消息消費(fèi)者，負(fù)責(zé)從 Broker 中獲取消息，并進(jìn)行相應(yīng)處理。

消息隊(duì)列模式

點(diǎn)對(duì)點(diǎn)模式：多個(gè)生產(chǎn)者可以向同一個(gè)消息隊(duì)列發(fā)送消息，一個(gè)具體的消息只能由一個(gè)消費(fèi)者消費(fèi)。

發(fā)布/訂閱模式：?jiǎn)蝹€(gè)消息可以被多個(gè)訂閱者并發(fā)的獲取和處理。

消息隊(duì)列應(yīng)用場(chǎng)景

應(yīng)用解耦 ：消息隊(duì)列減少了服務(wù)之間的耦合性，不同的服務(wù)可以通過(guò)消息隊(duì)列進(jìn)行通信，而不用關(guān)心彼此的實(shí)現(xiàn)細(xì)節(jié)。

異步處理 ：消息隊(duì)列本身是異步的，它允許接收者在消息發(fā)送很長(zhǎng)時(shí)間后再取回消息。

流量削鋒 ：當(dāng)上下游系統(tǒng)處理能力存在差距的時(shí)候，利用消息隊(duì)列做一個(gè)通用的”載體”，在下游有能力處理的時(shí)候，再進(jìn)行分發(fā)與處理。

日志處理 ：日志處理是指將消息隊(duì)列用在日志處理中，比如 Kafka 的應(yīng)用，解決大量日志傳輸?shù)膯?wèn)題。

消息通訊 ：消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊，比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列，或者聊天室等。

消息廣播 ：如果沒(méi)有消息隊(duì)列，每當(dāng)一個(gè)新的業(yè)務(wù)方接入，我們都要接入一次新接口。有了消息隊(duì)列，我們只需要關(guān)心消息是否送達(dá)了隊(duì)列，至于誰(shuí)希望訂閱，是下游的事情，無(wú)疑極大地減少了開(kāi)發(fā)和聯(lián)調(diào)的工作量。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

常用消息隊(duì)列

由于官方社區(qū)現(xiàn)在對(duì) ActiveMQ 5.x 維護(hù)越來(lái)越少，較少在大規(guī)模吞吐的場(chǎng)景中使用，所以我們主要講解 Kafka、RabbitMQ 和 RocketMQ。

Kafka

Apache Kafka 最初由 LinkedIn 公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)，之后成為 Apache 項(xiàng)目的一部分，號(hào)稱(chēng)大數(shù)據(jù)的殺手锏，在數(shù)據(jù)采集、傳輸、存儲(chǔ)的過(guò)程中發(fā)揮著舉足輕重的作用。

它是一個(gè)分布式的，支持多分區(qū)、多副本，基于 Zookeeper 的分布式消息流平臺(tái) ，它同時(shí)也是一款開(kāi)源的基于發(fā)布訂閱模式的消息引擎系統(tǒng)。

重要概念

主題（Topic） ：消息的種類(lèi)稱(chēng)為主題，可以說(shuō)一個(gè)主題代表了一類(lèi)消息，相當(dāng)于是對(duì)消息進(jìn)行分類(lèi)，主題就像是數(shù)據(jù)庫(kù)中的表。

分區(qū)（partition） ：主題可以被分為若干個(gè)分區(qū)，同一個(gè)主題中的分區(qū)可以不在一個(gè)機(jī)器上，有可能會(huì)部署在多個(gè)機(jī)器上，由此來(lái)實(shí)現(xiàn) kafka 的伸縮性。

批次 ：為了提高效率， 消息會(huì)分批次寫(xiě)入 Kafka，批次就代指的是一組消息。

消費(fèi)者群組（Consumer Group） ：消費(fèi)者群組指的就是由一個(gè)或多個(gè)消費(fèi)者組成的群體。

Broker : 一個(gè)獨(dú)立的 Kafka 服務(wù)器就被稱(chēng)為 broker，broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量，并提交消息到磁盤(pán)保存。

Broker 集群 ：broker 集群由一個(gè)或多個(gè) broker 組成。

重平衡（Rebalance） ：消費(fèi)者組內(nèi)某個(gè)消費(fèi)者實(shí)例掛掉后，其他消費(fèi)者實(shí)例自動(dòng)重新分配訂閱主題分區(qū)的過(guò)程。

Kafka 架構(gòu)

一個(gè)典型的 Kafka 集群中包含 Producer、broker、Consumer Group、Zookeeper 集群。

Kafka 通過(guò) Zookeeper 管理集群配置，選舉 leader，以及在 Consumer Group 發(fā)生變化時(shí)進(jìn)行 rebalance。Producer 使用 push 模式將消息發(fā)布到 broker，Consumer 使用 pull 模式從 broker 訂閱并消費(fèi)消息。

Kafka 工作原理

消息經(jīng)過(guò)序列化后，通過(guò)不同的分區(qū)策略，找到對(duì)應(yīng)的分區(qū)。

相同主題和分區(qū)的消息，會(huì)被存放在同一個(gè)批次里 ，然后由一個(gè)獨(dú)立的線(xiàn)程負(fù)責(zé)把它們發(fā)到 Kafka Broker 上。

分區(qū)的策略包括順序輪詢(xún)、隨機(jī)輪詢(xún)和 key hash 這 3 種方式，那什么是分區(qū)呢？

分區(qū)是 Kafka 讀寫(xiě)數(shù)據(jù)的最小粒度，比如主題 A 有 15 條消息，有 5 個(gè)分區(qū)，如果采用順序輪詢(xún)的方式，15 條消息會(huì)順序分配給這 5 個(gè)分區(qū)，后續(xù)消費(fèi)的時(shí)候，也是按照分區(qū)粒度消費(fèi)。

由于分區(qū)可以部署在多個(gè)不同的機(jī)器上，所以可以通過(guò)分區(qū)實(shí)現(xiàn) Kafka 的伸縮性，比如主題 A 的 5 個(gè)分區(qū)，分別部署在 5 臺(tái)機(jī)器上，如果下線(xiàn)一臺(tái)，分區(qū)就變?yōu)?4。

Kafka 消費(fèi)是通過(guò)消費(fèi)群組完成，同一個(gè)消費(fèi)者群組，一個(gè)消費(fèi)者可以消費(fèi)多個(gè)分區(qū)，但是一個(gè)分區(qū)，只能被一個(gè)消費(fèi)者消費(fèi)。

如果消費(fèi)者增加，會(huì)觸發(fā) Rebalance，也就是分區(qū)和消費(fèi)者需要重新配對(duì) 。

不同的消費(fèi)群組互不干涉 ，比如下圖的 2 個(gè)消費(fèi)群組，可以分別消費(fèi)這 4 個(gè)分區(qū)的消息，互不影響。

RocketMQ

RocketMQ 是阿里開(kāi)源的消息中間件，它是純 Java 開(kāi)發(fā)，具有高性能、高可靠、高實(shí)時(shí)、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。

RocketMQ 思路起源于 Kafka，但并不是 Kafka 的一個(gè) Copy，它對(duì)消息的可靠傳輸及事務(wù)性做了優(yōu)化 ，目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計(jì)算、消息推送、日志流式處理、binlog 分發(fā)等場(chǎng)景。

重要概念

Name 服務(wù)器（NameServer） ：充當(dāng)注冊(cè)中心，類(lèi)似 Kafka 中的 Zookeeper。

Broker : 一個(gè)獨(dú)立的 RocketMQ 服務(wù)器就被稱(chēng)為 broker，broker 接收來(lái)自生產(chǎn)者的消息，為消息設(shè)置偏移量。

主題（Topic） ：消息的第一級(jí)類(lèi)型，一條消息必須有一個(gè) Topic。

子主題（Tag） ：消息的第二級(jí)類(lèi)型，同一業(yè)務(wù)模塊不同目的的消息就可以用相同 Topic 和不同的 Tag 來(lái)標(biāo)識(shí)。

分組（Group） ：一個(gè)組可以訂閱多個(gè) Topic，包括生產(chǎn)者組（Producer Group）和消費(fèi)者組（Consumer Group）。

隊(duì)列（Queue） ：可以類(lèi)比 Kafka 的分區(qū) Partition。

RocketMQ 工作原理

RockerMQ 中的消息模型就是按照主題模型所實(shí)現(xiàn)的，包括 Producer Group、Topic、Consumer Group 三個(gè)角色。

為了提高并發(fā)能力，一個(gè) Topic 包含多個(gè) Queue ，生產(chǎn)者組根據(jù)主題將消息放入對(duì)應(yīng)的 Topic，下圖是采用輪詢(xún)的方式找到里面的 Queue。

RockerMQ 中的消費(fèi)群組和 Queue，可以類(lèi)比 Kafka 中的消費(fèi)群組和 Partition：不同的消費(fèi)者組互不干擾，一個(gè) Queue 只能被一個(gè)消費(fèi)者消費(fèi)，一個(gè)消費(fèi)者可以消費(fèi)多個(gè) Queue。

消費(fèi) Queue 的過(guò)程中，通過(guò)偏移量記錄消費(fèi)的位置。

RocketMQ 架構(gòu)

RocketMQ 技術(shù)架構(gòu)中有四大角色 NameServer、Broker、Producer 和 Consumer，下面主要介紹 Broker。

Broker 用于存放 Queue，一個(gè) Broker 可以配置多個(gè) Topic，一個(gè) Topic 中存在多個(gè) Queue。

如果某個(gè) Topic 消息量很大，應(yīng)該給它多配置幾個(gè) Queue，并且盡量多分布在不同 broker 上，以減輕某個(gè) broker 的壓力。Topic 消息量都比較均勻的情況下，如果某個(gè) broker 上的隊(duì)列越多，則該 broker 壓力越大。

簡(jiǎn)單提一下，Broker 通過(guò)集群部署，并且提供了 master/slave 的結(jié)構(gòu)，slave 定時(shí)從 master 同步數(shù)據(jù)（同步刷盤(pán)或者異步刷盤(pán)），如果 master 宕機(jī)，則 slave 提供消費(fèi)服務(wù)，但是不能寫(xiě)入消息。

看到這里，大家應(yīng)該可以發(fā)現(xiàn)，RocketMQ 的設(shè)計(jì)和 Kafka 真的很像！

RabbitMQ

RabbitMQ 2007 年發(fā)布，是使用 Erlang 語(yǔ)言開(kāi)發(fā)的開(kāi)源消息隊(duì)列系統(tǒng)，基于 AMQP 協(xié)議來(lái)實(shí)現(xiàn)。

AMQP 的主要特征是面向消息、隊(duì)列、路由、可靠性、安全。AMQP 協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對(duì)數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場(chǎng)景，對(duì)性能和吞吐量的要求還在其次。

重要概念

信道（Channel） ：消息讀寫(xiě)等操作在信道中進(jìn)行，客戶(hù)端可以建立多個(gè)信道，每個(gè)信道代表一個(gè)會(huì)話(huà)任務(wù)。

交換器（Exchange） ：接收消息，按照路由規(guī)則將消息路由到一個(gè)或者多個(gè)隊(duì)列；如果路由不到，或者返回給生產(chǎn)者，或者直接丟棄。

路由鍵（RoutingKey） ：生產(chǎn)者將消息發(fā)送給交換器的時(shí)候，會(huì)發(fā)送一個(gè) RoutingKey，用來(lái)指定路由規(guī)則，這樣交換器就知道把消息發(fā)送到哪個(gè)隊(duì)列。

綁定（Binding） ：交換器和消息隊(duì)列之間的虛擬連接，綁定中可以包含一個(gè)或者多個(gè) RoutingKey。

RabbitMQ 工作原理

AMQP 協(xié)議模型由三部分組成：生產(chǎn)者、消費(fèi)者和服務(wù)端，執(zhí)行流程如下：

生產(chǎn)者是連接到 Server，建立一個(gè)連接，開(kāi)啟一個(gè)信道。

生產(chǎn)者聲明交換器和隊(duì)列，設(shè)置相關(guān)屬性，并通過(guò)路由鍵將交換器和隊(duì)列進(jìn)行綁定。

消費(fèi)者也需要進(jìn)行建立連接，開(kāi)啟信道等操作，便于接收消息。

生產(chǎn)者發(fā)送消息，發(fā)送到服務(wù)端中的虛擬主機(jī)。

虛擬主機(jī)中的交換器根據(jù)路由鍵選擇路由規(guī)則，發(fā)送到不同的消息隊(duì)列中。

訂閱了消息隊(duì)列的消費(fèi)者就可以獲取到消息，進(jìn)行消費(fèi)。

常用交換器

RabbitMQ 常用的交換器類(lèi)型有 direct、topic、fanout、headers 四種。

具體的使用方法，可以參考官網(wǎng)：

官網(wǎng)入口：https://www.rabbitmq.com/getstarted.html

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

消息隊(duì)列對(duì)比&選型

消息隊(duì)列對(duì)比

Kafka

優(yōu)點(diǎn)：

高吞吐、低延遲 ：Kafka 最大的特點(diǎn)就是收發(fā)消息非?？欤琄afka 每秒可以處理幾十萬(wàn)條消息，它的最低延遲只有幾毫秒；

高伸縮性 ：每個(gè)主題（topic）包含多個(gè)分區(qū)（partition），主題中的分區(qū)可以分布在不同的主機(jī)（broker）中；

高穩(wěn)定性 ：Kafka 是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，某個(gè)節(jié)點(diǎn)宕機(jī)，Kafka 集群能夠正常工作；

持久性、可靠性、可回溯 ：Kafka 能夠允許數(shù)據(jù)的持久化存儲(chǔ)，消息被持久化到磁盤(pán)，并支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失，支持消息回溯；

消息有序：通過(guò)控制能夠保證所有消息被消費(fèi)且僅被消費(fèi)一次；

有優(yōu)秀的第三方 Kafka Web 管理界面 Kafka-Manager，在日志領(lǐng)域比較成熟，被多家公司和多個(gè)開(kāi)源項(xiàng)目使用。

缺點(diǎn)：

Kafka 單機(jī)超過(guò) 64 個(gè)隊(duì)列/分區(qū)，Load 會(huì)發(fā)生明顯的飆高現(xiàn)象，隊(duì)列越多，load 越高，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)；

不支持消息路由，不支持延遲發(fā)送，不支持消息重試；

社區(qū)更新較慢。

RocketMQ

優(yōu)點(diǎn)：

高吞吐 ：借鑒 Kafka 的設(shè)計(jì)，單一隊(duì)列百萬(wàn)消息的堆積能力；

高伸縮性 ：靈活的分布式橫向擴(kuò)展部署架構(gòu)，整體架構(gòu)其實(shí)和 kafka 很像；

高容錯(cuò)性 ：通過(guò)ACK機(jī)制，保證消息一定能正常消費(fèi)；

持久化、可回溯 ：消息可以持久化到磁盤(pán)中，支持消息回溯；

消息有序：在一個(gè)隊(duì)列中可靠的先進(jìn)先出（FIFO）和嚴(yán)格的順序傳遞；

支持發(fā)布/訂閱和點(diǎn)對(duì)點(diǎn)消息模型，支持拉、推兩種消息模式；

提供 docker 鏡像用于隔離測(cè)試和云集群部署，提供配置、指標(biāo)和監(jiān)控等功能豐富的 Dashboard。

缺點(diǎn)：

不支持消息路由，支持的客戶(hù)端語(yǔ)言不多，目前是 java 及 c++，其中 c++ 不成熟 ；

部分支持消息有序：需要將同一類(lèi)的消息 hash 到同一個(gè)隊(duì)列 Queue 中，才能支持消息的順序，如果同一類(lèi)消息散落到不同的 Queue中，就不能支持消息的順序。

社區(qū)活躍度一般。

RabbitMQ

優(yōu)點(diǎn)：

支持幾乎所有最受歡迎的編程語(yǔ)言 ：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；

支持消息路由 ：RabbitMQ 可以通過(guò)不同的交換器支持不同種類(lèi)的消息路由；

消息時(shí)序 ：通過(guò)延時(shí)隊(duì)列，可以指定消息的延時(shí)時(shí)間，過(guò)期時(shí)間TTL等；

支持容錯(cuò)處理：通過(guò)交付重試和死信交換器（DLX）來(lái)處理消息處理故障；

提供了一個(gè)易用的用戶(hù)界面，使得用戶(hù)可以監(jiān)控和管理消息 Broker；

社區(qū)活躍度高。

缺點(diǎn)：

Erlang 開(kāi)發(fā)，很難去看懂源碼，不利于做二次開(kāi)發(fā)和維護(hù) ，基本只能依賴(lài)于開(kāi)源社區(qū)的快速維護(hù)和修復(fù) bug；

RabbitMQ 吞吐量會(huì)低一些 ，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重；

不支持消息有序、持久化不好、不支持消息回溯、伸縮性一般。

消息隊(duì)列選型

Kafka：追求高吞吐量，一開(kāi)始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù) ，大型公司建議可以選用，如果有日志采集功能，肯定是首選 kafka。

RocketMQ：天生為金融互聯(lián)網(wǎng)領(lǐng)域而生，對(duì)于可靠性要求很高的場(chǎng)景 ，尤其是電商里面的訂單扣款，以及業(yè)務(wù)削峰，在大量交易涌入時(shí)，后端可能無(wú)法及時(shí)處理的情況。RocketMQ 在穩(wěn)定性上可能更值得信賴(lài)，這些業(yè)務(wù)場(chǎng)景在阿里雙 11 已經(jīng)經(jīng)歷了多次考驗(yàn)，如果你的業(yè)務(wù)有上述并發(fā)場(chǎng)景，建議可以選擇 RocketMQ。

RabbitMQ：結(jié)合 erlang 語(yǔ)言本身的并發(fā)優(yōu)勢(shì)，性能較好，社區(qū)活躍度也比較高，但是不利于做二次開(kāi)發(fā)和維護(hù)，不過(guò) RabbitMQ 的社區(qū)十分活躍，可以解決開(kāi)發(fā)過(guò)程中遇到的 bug。如果你的數(shù)據(jù)量沒(méi)有那么大，小公司優(yōu)先選擇功能比較完備的 RabbitMQ。

審核編輯：劉清