1.RabbitMQ是什么？

RabbitMQ是一款開源的，Erlang編寫的，基于AMQP（高級(jí)消息隊(duì)列協(xié)議）協(xié)議的消息中間件。

2.為什么要使用消息隊(duì)列？

從本質(zhì)上來說是因?yàn)榛ヂ?lián)網(wǎng)的快速發(fā)展，業(yè)務(wù)不斷擴(kuò)張，促使技術(shù)架構(gòu)需要不斷的演進(jìn)。

從以前的單體架構(gòu)到現(xiàn)在的微服務(wù)架構(gòu)，成百上千的服務(wù)之間相互調(diào)用和依賴。從互聯(lián)網(wǎng)初期一個(gè)服務(wù)器上有 100 個(gè)在線用戶已經(jīng)很了不得，到現(xiàn)在坐擁10億日活的微信。此時(shí)，我們需要有一個(gè)「工具」來解耦服務(wù)之間的關(guān)系、控制資源合理合時(shí)的使用以及緩沖流量洪峰等等。因此，消息隊(duì)列就應(yīng)運(yùn)而生了。

它常用來實(shí)現(xiàn)：異步處理、服務(wù)解耦、流量控制（削峰）。

3.說說RabbitMQ中的幾大組件

• Broker：接收和分發(fā)消息的應(yīng)用，RabbitMQ Server 就是 Message Broker。
• Virtual host：出于多租戶和安全因素設(shè)計(jì)的，把 AMQP 的基本組件劃分到一個(gè)虛擬的分組中，類似于網(wǎng)絡(luò)中的 namespace 概念。當(dāng)多個(gè)不同的用戶使用同一個(gè) RabbitMQ server 提供的服務(wù)時(shí)，可以劃分出多個(gè) vhost，每個(gè)用戶在自己的 vhost 創(chuàng)建 exchange／queue 等。
• Connection：publisher／consumer 和 broker 之間的 TCP 連接Channel：如果每一次訪問 RabbitMQ 都建立一個(gè) Connection，在消息量大的時(shí)候建立 TCP Connection 的開銷將是巨大的，效率也較低。Channel 是在 connection 內(nèi)部建立的邏輯連接，如果應(yīng)用程序支持多線程，通常每個(gè) thread 創(chuàng)建單獨(dú)的 channel 進(jìn)行通訊，AMQP method 包含了 channel id 幫助客戶端和 message broker 識(shí)別 channel，所以 channel 之間是完全隔離的。 l Channel 作為輕量級(jí)的Connection 極大減少了操作系統(tǒng)建立 TCP connection 的開銷。
• Exchange ： message 到達(dá) broker 的第一站，根據(jù)分發(fā)規(guī)則，匹配查詢表中的 routing key，分發(fā)消息到 queue 中去。常用的類型有：direct (point-to-point), topic (publish-subscribe) and fanout(multicast)。
• Queue ： 消息最終被送到這里等待 consumer 取走。
• Binding ： exchange 和 queue 之間的虛擬連接，binding 中可以包含 routing key，Binding 信息被保存到 exchange 中的查詢表中，用于 message 的分發(fā)依據(jù)。
• Producer：消息生產(chǎn)者，就是投遞消息的一方。消息一般包含兩個(gè)部分：消息體（payload)和標(biāo)簽(Label)。
• Consumer：消費(fèi)消息，也就是接收消息的一方。消費(fèi)者連接到RabbitMQ服務(wù)器，并訂閱到隊(duì)列上。消費(fèi)消息時(shí)只消費(fèi)消息體，丟棄標(biāo)簽。

4.消息隊(duì)列有什么優(yōu)缺點(diǎn)？

優(yōu)點(diǎn)上面已經(jīng)說了，就是在特殊場(chǎng)景下有其對(duì)應(yīng)的好處，解耦、異步、削峰。缺點(diǎn)有以下幾個(gè)：

• 系統(tǒng)可用性降低：系統(tǒng)引入的外部依賴越多，越容易掛掉。萬一 MQ 掛了，MQ 一掛，整套系統(tǒng)崩 潰，你不就完了？
• 系統(tǒng)復(fù)雜度提高：硬生生加個(gè) MQ 進(jìn)來，你怎么保證消息沒有重復(fù)消費(fèi)？怎么處理消息丟失的情況？
• 怎么保證消息傳遞的順序性？問題一大堆。
• 一致性問題：A 系統(tǒng)處理完了直接返回成功了，人都以為你這個(gè)請(qǐng)求就成功了；但是問題是，要是 BCD 三個(gè)系統(tǒng)那里，BD 兩個(gè)系統(tǒng)寫庫成功了，結(jié)果 C 系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致 了。

5.如何保證消息的可靠性？

消息到MQ的過程中搞丟，MQ自己搞丟，MQ到消費(fèi)過程中搞丟。

生產(chǎn)者到RabbitMQ：事務(wù)機(jī)制和Confirm機(jī)制，注意：事務(wù)機(jī)制和 Confirm 機(jī)制是互斥的，兩者不能共存，會(huì)導(dǎo)致 RabbitMQ 報(bào)錯(cuò)。

RabbitMQ自身：持久化、集群、普通模式、鏡像模式。

RabbitMQ到消費(fèi)者：basicAck機(jī)制、死信隊(duì)列、消息補(bǔ)償機(jī)制。

6.RabbitMQ中常見交換機(jī)類型有哪些？

• fanout：把所有發(fā)送到該交換器的消息路由到所有與該交換器綁定的隊(duì)列中。
• direct：把消息路由到BindingKey和RoutingKey完全匹配的隊(duì)列中。
• topic：

RoutingKey 為一個(gè) 點(diǎn)號(hào)'.': 分隔的字符串。比如: szh.name.love

BindingKey和RoutingKey一樣也是點(diǎn)號(hào)“.“分隔的字符串。

BindingKey可使用 * 和 # 用于做模糊匹配，*匹配一個(gè)單詞，#匹配多個(gè)或者0個(gè)

7.生產(chǎn)者發(fā)送消息的過程是怎樣的？

• Producer先連接到Broker，建立連接Connection，開啟一個(gè)信道(Channel)。
• Producer聲明一個(gè)交換器并設(shè)置好相關(guān)屬性。
• Producer聲明一個(gè)隊(duì)列并設(shè)置好相關(guān)屬性。
• Producer通過路由鍵將交換器和隊(duì)列綁定起來。
• Producer發(fā)送消息到Broker,其中包含路由鍵、交換器等信息。
• 相應(yīng)的交換器根據(jù)接收到的路由鍵查找匹配的隊(duì)列。
• 如果找到，將消息存入對(duì)應(yīng)的隊(duì)列，如果沒有找到，會(huì)根據(jù)生產(chǎn)者的配置丟棄或者退回給生產(chǎn)者。
• 關(guān)閉信道，關(guān)閉連接。

8.消費(fèi)者接收消息的過程是怎樣的？

• Producer先連接到Broker，建立連接Connection，開啟一個(gè)信道(Channel)。
• 向Broker請(qǐng)求消費(fèi)響應(yīng)的隊(duì)列中的消息，可能會(huì)設(shè)置響應(yīng)的回調(diào)函數(shù)。
• 等待Broker回應(yīng)并投遞相應(yīng)隊(duì)列中的消息，接收消息。
• 消費(fèi)者確認(rèn)收到的消息，ack。
• RabbitMQ從隊(duì)列中刪除已經(jīng)確定的消息。
• 關(guān)閉信道，關(guān)閉連接。

9.交換機(jī)無法根據(jù)自身類型和路由鍵找到符合條件隊(duì)列時(shí)，有哪些處理方法？

• mandatory ：true 返回消息給生產(chǎn)者。
• mandatory : false 直接丟棄。

10.什么是死信隊(duì)列？導(dǎo)致死信的原因有哪些？

死信，DLX，全稱為 Dead-Letter-Exchange，死信交換器，死信郵箱。顧名思義就是無法被消費(fèi)的消息，一般來說，producer 將消息投遞到 broker 或者直接到 queue 里了，consumer 從 queue 取出消息進(jìn)行消費(fèi)，但某些時(shí)候由于特定的原因?qū)е?queue 中的某些消息無法被消費(fèi)，這樣的消息如果沒有后續(xù)的處理，就變成了死信，有死信自然就有了死信隊(duì)列。

• 消息 TTL 過期
• 隊(duì)列達(dá)到最大長度 (隊(duì)列滿了，無法再添加數(shù)據(jù)到 mq 中)
• 消息被拒絕 (basic.reject 或 basic.nack) 并且 requeue=false.

11.什么是延遲隊(duì)列？使用場(chǎng)景有哪些？

存儲(chǔ)對(duì)應(yīng)的延遲消息，指當(dāng)消息被發(fā)送以后，并不想讓消費(fèi)者立刻拿到消息，而是等待特定時(shí)間后，消費(fèi)者才能拿到這個(gè)消息進(jìn)行消費(fèi)。

• 訂單在十分鐘之內(nèi)未支付則自動(dòng)取消。
• 新創(chuàng)建的店鋪，如果在十天內(nèi)都沒有上傳過商品，則自動(dòng)發(fā)送消息提醒。
• 用戶注冊(cè)成功后，如果三天內(nèi)沒有登陸則進(jìn)行短信提醒。
• 用戶發(fā)起退款，如果三天內(nèi)沒有得到處理則通知相關(guān)運(yùn)營人員。
• 預(yù)定會(huì)議后，需要在預(yù)定的時(shí)間點(diǎn)前十分鐘通知各個(gè)與會(huì)人員參加會(huì)議

12.什么是優(yōu)先級(jí)隊(duì)列？

• 優(yōu)先級(jí)高的隊(duì)列會(huì)先被消費(fèi)。
• 可以通過 x-max-priority 參數(shù)來實(shí)現(xiàn)。
• 當(dāng)消費(fèi)速度大于生產(chǎn)速度且Broker沒有堆積的情況下，優(yōu)先級(jí)顯得沒有意義。

13.RabbitMQ中的事務(wù)機(jī)制？

RabbitMQ 客戶端中與事務(wù)機(jī)制相關(guān)的方法有三個(gè):

channel.txSelect 用于將當(dāng)前的信道設(shè)置成事務(wù)模式。

channel.txCommit 用于提交事務(wù) 。

channel.txRollback 用于事務(wù)回滾，如果在事務(wù)提交執(zhí)行之前由于 RabbitMQ 異常崩潰或者其他原因拋出異常，通過txRollback來回滾。

14.RabbitMQ中的發(fā)送確認(rèn)機(jī)制？

生產(chǎn)者將信道設(shè)置成 confirm 模式，一旦信道進(jìn)入 confirm 模式， 所有在該信道上面發(fā)布的消息都將會(huì)被指派一個(gè)唯一的 ID(從 1 開始)，一旦消息被投遞到所有匹配的隊(duì)列之后，broker就會(huì)發(fā)送一個(gè)確認(rèn)給生產(chǎn)者(包含消息的唯一 ID)，這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊(duì)列了。

confirm 模式最大的好處在于他是異步的，一旦發(fā)布一條消息，生產(chǎn)者應(yīng)用程序就可以在等信道返回確認(rèn)的同時(shí)繼續(xù)發(fā)送下一條消息，當(dāng)消息最終得到確認(rèn)之后，生產(chǎn)者應(yīng)用便可以通過回調(diào)方法來處理該確認(rèn)消息，如果 RabbitMQ 因?yàn)樽陨韮?nèi)部錯(cuò)誤導(dǎo)致消息丟失，就會(huì)發(fā)送一條 nack 消息，生產(chǎn)者應(yīng)用程序同樣可以在回調(diào)方法中處理該 nack 消息。

15.如何保證RabbitMQ消息隊(duì)列的高可用？

RabbitMQ 有三種模式：單機(jī)模式，普通集群模式，鏡像集群模式。

單機(jī)模式：就是demo級(jí)別的，一般就是你本地啟動(dòng)了玩玩兒的，沒人生產(chǎn)用單機(jī)模式

普通集群模式：意思就是在多臺(tái)機(jī)器上啟動(dòng)多個(gè)RabbitMQ實(shí)例，每個(gè)機(jī)器啟動(dòng)一個(gè)。

鏡像集群模式：這種模式，才是所謂的RabbitMQ的高可用模式，跟普通集群模式不一樣的是，你創(chuàng)建的queue，無論元數(shù)據(jù)(元數(shù)據(jù)指RabbitMQ的配置數(shù)據(jù))還是queue里的消息都會(huì)存在于多個(gè)實(shí)例上，然后每次你寫消息到queue的時(shí)候，都會(huì)自動(dòng)把消息到多個(gè)實(shí)例的queue里進(jìn)行消息同步。

到此這篇關(guān)于Java面試高頻問題之RabbitMQ系列全面解析的文章就介紹到這了,更多相關(guān)Java RabbitMQ系列內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論