Java面试——RabbitMQ系列总结
1.RabbitMQ是什么？
RabbitMQ是一款開源的，Erlang編寫的，基于AMQP（高級消息隊列協議）協議的消息中間件。
2.為什么要使用消息隊列？
從本質上來說是因為互聯網的快速發展，業務不斷擴張，促使技術架構需要不斷的演進。
從以前的單體架構到現在的微服務架構，成百上千的服務之間相互調用和依賴。從互聯網初期一個服務器上有 100 個在線用戶已經很了不得，到現在坐擁10億日活的微信。此時，我們需要有一個「工具」來解耦服務之間的關系、控制資源合理合時的使用以及緩沖流量洪峰等等。因此，消息隊列就應運而生了。
它常用來實現：異步處理、服務解耦、流量控制（削峰）。
3.說說RabbitMQ中的幾大組件
- Broker：接收和分發消息的應用，RabbitMQ Server 就是 Message Broker。
- Virtual host：出于多租戶和安全因素設計的，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似于網絡中的 namespace 概念。當多個不同的用戶使用同一個 RabbitMQ server 提供的服務時，可以劃分出多個 vhost，每個用戶在自己的 vhost 創建 exchange／queue 等。
- Connection：publisher／consumer 和 broker 之間的 TCP 連接Channel：如果每一次訪問 RabbitMQ 都建立一個 Connection，在消息量大的時候建立 TCP Connection 的開銷將是巨大的，效率也較低。Channel 是在 connection 內部建立的邏輯連接，如果應用程序支持多線程，通常每個 thread 創建單獨的 channel 進行通訊，AMQP method 包含了 channel id 幫助客戶端和 message broker 識別 channel，所以 channel 之間是完全隔離的。 l Channel 作為輕量級的Connection 極大減少了操作系統建立 TCP connection 的開銷。
- Exchange ： message 到達 broker 的第一站，根據分發規則，匹配查詢表中的 routing key，分發消息到 queue 中去。常用的類型有：direct (point-to-point), topic (publish-subscribe) and fanout(multicast)。
- Queue ： 消息最終被送到這里等待 consumer 取走。
- Binding ： exchange 和 queue 之間的虛擬連接，binding 中可以包含 routing key，Binding 信息被保存到 exchange 中的查詢表中，用于 message 的分發依據。
- Producer：消息生產者，就是投遞消息的一方。消息一般包含兩個部分：消息體（payload)和標簽(Label)。
- Consumer：消費消息，也就是接收消息的一方。消費者連接到RabbitMQ服務器，并訂閱到隊列上。消費消息時只消費消息體，丟棄標簽。
4.消息隊列有什么優缺點？
優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰。缺點有以下幾個：
- 系統可用性降低：系統引入的外部依賴越多，越容易掛掉。萬一 MQ 掛了，MQ 一掛，整套系統崩 潰，你不就完了？
- 系統復雜度提高：硬生生加個 MQ 進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？
- 怎么保證消息傳遞的順序性？問題一大堆。
- 一致性問題：A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致 了。
5.如何保證消息的可靠性？
消息到MQ的過程中搞丟，MQ自己搞丟，MQ到消費過程中搞丟。
生產者到RabbitMQ：事務機制和Confirm機制，注意：事務機制和 Confirm 機制是互斥的，兩者不能共存，會導致 RabbitMQ 報錯。
RabbitMQ自身：持久化、集群、普通模式、鏡像模式。
RabbitMQ到消費者：basicAck機制、死信隊列、消息補償機制。
6.RabbitMQ中常見交換機類型有哪些？
- fanout：把所有發送到該交換器的消息路由到所有與該交換器綁定的隊列中。
- direct：把消息路由到BindingKey和RoutingKey完全匹配的隊列中。
- topic：
BindingKey和RoutingKey一樣也是點號“.“分隔的字符串。
BindingKey可使用 * 和 # 用于做模糊匹配，*匹配一個單詞，#匹配多個或者0個
7.生產者發送消息的過程是怎樣的？
8.消費者接收消息的過程是怎樣的？
9.交換機無法根據自身類型和路由鍵找到符合條件隊列時，有哪些處理方法？
- mandatory ：true 返回消息給生產者。
- mandatory : false 直接丟棄。
10.什么是死信隊列？導致死信的原因有哪些？
死信，DLX，全稱為 Dead-Letter-Exchange，死信交換器，死信郵箱。顧名思義就是無法被消費的消息，一般來說，producer 將消息投遞到 broker 或者直接到 queue 里了，consumer 從 queue 取出消息進行消費，但某些時候由于特定的原因導致 queue 中的某些消息無法被消費，這樣的消息如果沒有后續的處理，就變成了死信，有死信自然就有了死信隊列。
- 消息 TTL 過期
- 隊列達到最大長度 (隊列滿了，無法再添加數據到 mq 中)
- 消息被拒絕 (basic.reject 或 basic.nack) 并且 requeue=false.
11.什么是延遲隊列？使用場景有哪些？
存儲對應的延遲消息，指當消息被發送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。
12.什么是優先級隊列？
- 優先級高的隊列會先被消費。
- 可以通過 x-max-priority參數來實現。
- 當消費速度大于生產速度且Broker沒有堆積的情況下，優先級顯得沒有意義。
13.RabbitMQ中的事務機制？
RabbitMQ 客戶端中與事務機制相關的方法有三個:
channel.txSelect 用于將當前的信道設置成事務模式。
channel.txCommit 用于提交事務 。
channel.txRollback 用于事務回滾，如果在事務提交執行之前由于 RabbitMQ 異常崩潰或者其他原因拋出異常，通過txRollback來回滾。
14.RabbitMQ中的發送確認機制？
生產者將信道設置成 confirm 模式，一旦信道進入 confirm 模式， 所有在該信道上面發布的消息都將會被指派一個唯一的 ID(從 1 開始)，一旦消息被投遞到所有匹配的隊列之后，broker就會發送一個確認給生產者(包含消息的唯一 ID)，這就使得生產者知道消息已經正確到達目的隊列了。
15.如何保證RabbitMQ消息隊列的高可用？
RabbitMQ 有三種模式：單機模式，普通集群模式，鏡像集群模式。
單機模式：就是demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產用單機模式
普通集群模式：意思就是在多臺機器上啟動多個RabbitMQ實例，每個機器啟動一個。
鏡像集群模式：這種模式，才是所謂的RabbitMQ的高可用模式，跟普通集群模式不一樣的是，你創建的queue，無論元數據(元數據指RabbitMQ的配置數據)還是queue里的消息都會存在于多個實例上，然后每次你寫消息到queue的時候，都會自動把消息到多個實例的queue里進行消息同步。
總結
以上是生活随笔為你收集整理的Java面试——RabbitMQ系列总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SSM 框架整合 spring 发送邮件
- 下一篇： Java Stream Collecto