1.RabbitMQ是什么？

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

2.為什么要使用消息隊列？

從本質上來說是因為互聯(lián)網的快速發(fā)展，業(yè)務不斷擴張，促使技術架構需要不斷的演進。

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

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

3.說說RabbitMQ中的幾大組件

• Broker：接收和分發(fā)消息的應用，RabbitMQ Server 就是 Message Broker。
• Virtual host：出于多租戶和安全因素設計的，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似于網絡中的 namespace 概念。當多個不同的用戶使用同一個 RabbitMQ server 提供的服務時，可以劃分出多個 vhost，每個用戶在自己的 vhost 創(chuàng)建 exchange／queue 等。
• Connection：publisher／consumer 和 broker 之間的 TCP 連接Channel：如果每一次訪問 RabbitMQ 都建立一個 Connection，在消息量大的時候建立 TCP Connection 的開銷將是巨大的，效率也較低。Channel 是在 connection 內部建立的邏輯連接，如果應用程序支持多線程，通常每個 thread 創(chuàng)建單獨的 channel 進行通訊，AMQP method 包含了 channel id 幫助客戶端和 message broker 識別 channel，所以 channel 之間是完全隔離的。 l Channel 作為輕量級的Connection 極大減少了操作系統(tǒng)建立 TCP connection 的開銷。
• Exchange ： message 到達 broker 的第一站，根據分發(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ā)依據。
• Producer：消息生產者，就是投遞消息的一方。消息一般包含兩個部分：消息體（payload)和標簽(Label)。
• Consumer：消費消息，也就是接收消息的一方。消費者連接到RabbitMQ服務器，并訂閱到隊列上。消費消息時只消費消息體，丟棄標簽。

4.消息隊列有什么優(yōu)缺點？

優(yōu)點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰。缺點有以下幾個：

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

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

消息到MQ的過程中搞丟，MQ自己搞丟，MQ到消費過程中搞丟。

生產者到RabbitMQ：事務機制和Confirm機制，注意：事務機制和 Confirm 機制是互斥的，兩者不能共存，會導致 RabbitMQ 報錯。

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

RabbitMQ到消費者：basicAck機制、死信隊列、消息補償機制。

6.RabbitMQ中常見交換機類型有哪些？

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

RoutingKey 為一個 點號'.': 分隔的字符串。比如: szh.name.love

BindingKey和RoutingKey一樣也是點號“.“分隔的字符串。

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

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

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

8.消費者接收消息的過程是怎樣的？

• Producer先連接到Broker，建立連接Connection，開啟一個信道(Channel)。
• 向Broker請求消費響應的隊列中的消息，可能會設置響應的回調函數。
• 等待Broker回應并投遞相應隊列中的消息，接收消息。
• 消費者確認收到的消息，ack。
• RabbitMQ從隊列中刪除已經確定的消息。
• 關閉信道，關閉連接。

9.交換機無法根據自身類型和路由鍵找到符合條件隊列時，有哪些處理方法？

• mandatory ：true 返回消息給生產者。
• mandatory : false 直接丟棄。

10.什么是死信隊列？導致死信的原因有哪些？

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

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

11.什么是延遲隊列？使用場景有哪些？

存儲對應的延遲消息，指當消息被發(fā)送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。

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

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

• 優(yōu)先級高的隊列會先被消費。
• 可以通過 x-max-priority 參數來實現(xiàn)。
• 當消費速度大于生產速度且Broker沒有堆積的情況下，優(yōu)先級顯得沒有意義。

13.RabbitMQ中的事務機制？

RabbitMQ 客戶端中與事務機制相關的方法有三個:

channel.txSelect 用于將當前的信道設置成事務模式。

channel.txCommit 用于提交事務 。

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

14.RabbitMQ中的發(fā)送確認機制？

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

confirm 模式最大的好處在于他是異步的，一旦發(fā)布一條消息，生產者應用程序就可以在等信道返回確認的同時繼續(xù)發(fā)送下一條消息，當消息最終得到確認之后，生產者應用便可以通過回調方法來處理該確認消息，如果 RabbitMQ 因為自身內部錯誤導致消息丟失，就會發(fā)送一條 nack 消息，生產者應用程序同樣可以在回調方法中處理該 nack 消息。

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

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

單機模式：就是demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產用單機模式

普通集群模式：意思就是在多臺機器上啟動多個RabbitMQ實例，每個機器啟動一個。

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

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

最新評論