消息隊(duì)列中間件重要嗎？面試必問問題之一，你說重不重要。我有時(shí)會問同事，為啥你用 RabbitMQ，不用 Kafka，或者 RocketMQ 呢，他給我的回答 “因?yàn)楣居玫木褪沁@個，大家都這么用”，如果你去面試，直接就被 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ì)列是在消息的傳輸過程中保存消息的容器，用于接收消息并以文件的方式存儲，一個消息隊(duì)列可以被一個也可以被多個消費(fèi)者消費(fèi)，包含以下 3 元素：

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

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

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

消息隊(duì)列模式

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

發(fā)布/訂閱模式：單個消息可以被多個訂閱者并發(fā)的獲取和處理。

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

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

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

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

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

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

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

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

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

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

常用消息隊(duì)列

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

Kafka

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

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

重要概念

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

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

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

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

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

Broker 集群 ：broker 集群由一個或多個 broker 組成。

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

Kafka 架構(gòu)

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

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

Kafka 工作原理

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

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

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

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

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

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

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

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

RocketMQ

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

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

重要概念

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

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

主題（Topic） ：消息的第一級類型，一條消息必須有一個 Topic。

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

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

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

RocketMQ 工作原理

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

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

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

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

RocketMQ 架構(gòu)

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

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

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

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

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

RabbitMQ

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

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

重要概念

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

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

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

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

RabbitMQ 工作原理

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

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

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

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

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

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

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

常用交換器

RabbitMQ 常用的交換器類型有 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ǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

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

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

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

消息隊(duì)列對比

Kafka

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

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

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

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

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

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

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

缺點(diǎn)：

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

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

社區(qū)更新較慢。

RocketMQ

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

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

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

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

持久化、可回溯 ：消息可以持久化到磁盤中，支持消息回溯；

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

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

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

缺點(diǎn)：

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

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

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

RabbitMQ

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

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

支持消息路由 ：RabbitMQ 可以通過不同的交換器支持不同種類的消息路由；

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

支持容錯處理：通過交付重試和死信交換器（DLX）來處理消息處理故障；

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

社區(qū)活躍度高。

缺點(diǎn)：

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

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

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

消息隊(duì)列選型

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

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

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

審核編輯：劉清