溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Java RabbitMQ面試題有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Java RabbitMQ面試題有哪些”吧！
RabbitMQ是一款開源的，Erlang編寫的，基于AMQP（高級消息隊列協議）協議的消息中間件。
從本質上來說是因為互聯網的快速發展，業務不斷擴張，促使技術架構需要不斷的演進。
從以前的單體架構到現在的微服務架構，成百上千的服務之間相互調用和依賴。從互聯網初期一個服務器上有 100 個在線用戶已經很了不得，到現在坐擁10億日活的微信。此時，我們需要有一個「工具」來解耦服務之間的關系、控制資源合理合時的使用以及緩沖流量洪峰等等。因此，消息隊列就應運而生了。
它常用來實現：異步處理、服務解耦、流量控制（削峰）。
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服務器，并訂閱到隊列上。消費消息時只消費消息體，丟棄標簽。
優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰。缺點有以下幾個：
系統可用性降低：系統引入的外部依賴越多，越容易掛掉。萬一 MQ 掛了，MQ 一掛，整套系統崩 潰，你不就完了？
系統復雜度提高：硬生生加個 MQ 進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？
怎么保證消息傳遞的順序性？問題一大堆。
一致性問題：A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致 了。
消息到MQ的過程中搞丟，MQ自己搞丟，MQ到消費過程中搞丟。
生產者到RabbitMQ：事務機制和Confirm機制，注意：事務機制和 Confirm 機制是互斥的，兩者不能共存，會導致 RabbitMQ 報錯。
RabbitMQ自身：持久化、集群、普通模式、鏡像模式。
RabbitMQ到消費者：basicAck機制、死信隊列、消息補償機制。
fanout：把所有發送到該交換器的消息路由到所有與該交換器綁定的隊列中。
direct：把消息路由到BindingKey和RoutingKey完全匹配的隊列中。
topic：
RoutingKey 為一個 點號'.': 分隔的字符串。比如: szh.name.love
BindingKey和RoutingKey一樣也是點號“.“分隔的字符串。
BindingKey可使用 * 和 # 用于做模糊匹配，*匹配一個單詞，#匹配多個或者0個
Producer先連接到Broker，建立連接Connection，開啟一個信道(Channel)。
Producer聲明一個交換器并設置好相關屬性。
Producer聲明一個隊列并設置好相關屬性。
Producer通過路由鍵將交換器和隊列綁定起來。
Producer發送消息到Broker,其中包含路由鍵、交換器等信息。
相應的交換器根據接收到的路由鍵查找匹配的隊列。
如果找到，將消息存入對應的隊列，如果沒有找到，會根據生產者的配置丟棄或者退回給生產者。
關閉信道，關閉連接。
Producer先連接到Broker，建立連接Connection，開啟一個信道(Channel)。
向Broker請求消費響應的隊列中的消息，可能會設置響應的回調函數。
等待Broker回應并投遞相應隊列中的消息，接收消息。
消費者確認收到的消息，ack。
RabbitMQ從隊列中刪除已經確定的消息。
關閉信道，關閉連接。
mandatory ：true 返回消息給生產者。
mandatory : false 直接丟棄。
死信，DLX，全稱為 Dead-Letter-Exchange，死信交換器，死信郵箱。顧名思義就是無法被消費的消息，一般來說，producer 將消息投遞到 broker 或者直接到 queue 里了，consumer 從 queue 取出消息進行消費，但某些時候由于特定的原因導致 queue 中的某些消息無法被消費，這樣的消息如果沒有后續的處理，就變成了死信，有死信自然就有了死信隊列。
消息 TTL 過期
隊列達到最大長度 (隊列滿了，無法再添加數據到 mq 中)
消息被拒絕 (basic.reject 或 basic.nack) 并且 requeue=false.
存儲對應的延遲消息，指當消息被發送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。
訂單在十分鐘之內未支付則自動取消。
新創建的店鋪，如果在十天內都沒有上傳過商品，則自動發送消息提醒。
用戶注冊成功后，如果三天內沒有登陸則進行短信提醒。
用戶發起退款，如果三天內沒有得到處理則通知相關運營人員。
預定會議后，需要在預定的時間點前十分鐘通知各個與會人員參加會議
優先級高的隊列會先被消費。
可以通過 x-max-priority 參數來實現。
當消費速度大于生產速度且Broker沒有堆積的情況下，優先級顯得沒有意義。
RabbitMQ 客戶端中與事務機制相關的方法有三個:
channel.txSelect 用于將當前的信道設置成事務模式。
channel.txCommit 用于提交事務 。
channel.txRollback 用于事務回滾，如果在事務提交執行之前由于 RabbitMQ 異常崩潰或者其他原因拋出異常，通過txRollback來回滾。
生產者將信道設置成 confirm 模式，一旦信道進入 confirm 模式， 所有在該信道上面發布的消息都將會被指派一個唯一的 ID(從 1 開始)，一旦消息被投遞到所有匹配的隊列之后，broker就會發送一個確認給生產者(包含消息的唯一 ID)，這就使得生產者知道消息已經正確到達目的隊列了。
confirm 模式最大的好處在于他是異步的，一旦發布一條消息，生產者應用程序就可以在等信道返回確認的同時繼續發送下一條消息，當消息最終得到確認之后，生產者應用便可以通過回調方法來處理該確認消息，如果 RabbitMQ 因為自身內部錯誤導致消息丟失，就會發送一條 nack 消息，生產者應用程序同樣可以在回調方法中處理該 nack 消息。
RabbitMQ 有三種模式：單機模式，普通集群模式，鏡像集群模式。
單機模式：就是demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產用單機模式
普通集群模式：意思就是在多臺機器上啟動多個RabbitMQ實例，每個機器啟動一個。
鏡像集群模式：這種模式，才是所謂的RabbitMQ的高可用模式，跟普通集群模式不一樣的是，你創建的queue，無論元數據(元數據指RabbitMQ的配置數據)還是queue里的消息都會存在于多個實例上，然后每次你寫消息到queue的時候，都會自動把消息到多個實例的queue里進行消息同步。
感謝各位的閱讀，以上就是“Java RabbitMQ面試題有哪些”的內容了，經過本文的學習后，相信大家對Java RabbitMQ面試題有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
