【2021最新版】RabbitMQ面试题总结（32道题含答案解析）
文章目錄
-
-
- 1、什么是rabbitmq？
- 2、為什么要使用rabbitmq？
- 3、使用rabbitmq的場景。
- 4、如何確保消息正確地發(fā)送至RabbitMQ？如何確保消息接收方消費(fèi)了消息？
- 5.如何避免消息重復(fù)投遞或重復(fù)消費(fèi)？
- 6、消息基于什么傳輸？
- 7、消息如何分發(fā)？
- 8、消息怎么路由？
- 9、如何確保消息不丟失？
- 10、使用RabbitMQ有什么好處？
- 11、RabbitMQ的集群。
- 12、mq的缺點
- 13、什么是MQ ？
- 14、MQ的優(yōu)點。
- 15、解耦、異步、削峰是什么？
- 16、消息隊列有什么缺點？
- 17、你們公司生產(chǎn)環(huán)境用的是什么消息中間件？
- 18、Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么優(yōu)缺點？
- 19、MQ有哪些常見問題？如何解決這些問題？
- 20、RabbitMQ基本概念。
- 21、RabbitMQ的工作模式。
- 22、如何保證RabbitMQ消息的順序性？
- 23、消息如何分發(fā)？
- 24、消息怎么路由？
- 25、消息基于什么傳輸？
- 26、如何保證消息不被重復(fù)消費(fèi)？或者說，如何保證消息消費(fèi)時的冪等性？
- 27、如何確保消息正確地發(fā)送至 RabbitMQ？ 如何確保消息接收方消費(fèi)了消息？
- 28、如何保證RabbitMQ消息的可靠傳輸？
- 29、為什么不應(yīng)該對所有的message都使用持久化機(jī)制？
- 30、如何保證高可用的？RabbitMQ的集群？
- 31、如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續(xù)積壓幾小時，怎么辦？
- 32、設(shè)計MQ思路。
-
- 總結(jié)
最近面試的小伙伴很多，對此我整理了一份Java面試題手冊：基礎(chǔ)知識、JavaOOP、Java集合/泛型面試題、Java異常面試題、Java中的IO與NIO面試題、Java反射、Java序列化、Java注解、多線程&并發(fā)、JVM、Mysql、Redis、Memcached、MongoDB、Spring、SpringBoot、SpringCloud、RabbitMQ、Dubbo、MyBatis、ZooKeeper、數(shù)據(jù)結(jié)構(gòu)、算法、Elasticsearch、Kafka、微服務(wù)、Linux等等。可以分享給大家學(xué)習(xí)。【持續(xù)更新中】
完整版Java面試題地址：【2021最新版】Java面試真題匯總
序號
內(nèi)容
地址鏈接
1
【2021最新版】JavaOOP面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115288673
2
【2021最新版】Java基礎(chǔ)面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115485109
3
【2021最新版】多線程&并發(fā)面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115489616
4
【2021最新版】JVM面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115555086
5
【2021最新版】Mysql面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115561030
6
【2021最新版】Redis面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115642129
7
【2021最新版】Memcached面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115664662
8
【2021最新版】MongoDB面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115672336
9
【2021最新版】Spring面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115738909
10
【2021最新版】Spring Boot面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115771307
11
【2021最新版】Spring Cloud面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/115917190
12
【2021最新版】Dubbo面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116237861
13
【2021最新版】MyBatis面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116427170
14
【2021最新版】ZooKeeper面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116458096
15
【2021最新版】數(shù)據(jù)結(jié)構(gòu)面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116461620
16
【2021最新版】算法面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116461620
17
【2021最新版】Elasticsearch面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116656094
18
【2021最新版】Kafka面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116659584
19
【2021最新版】微服務(wù)面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116662109
20
【2021最新版】Linux面試題總結(jié)
https://blog.csdn.net/m0_48795607/article/details/116798880
1、什么是rabbitmq？
答：
采用AMQP高級消息隊列協(xié)議的一種消息隊列技術(shù),最大的特點就是消費(fèi)并不需要確保提供方存在,實現(xiàn)了服務(wù)之間的高度解耦。
2、為什么要使用rabbitmq？
答：
1、在分布式系統(tǒng)下具備異步,削峰,負(fù)載均衡等一系列高級功能；
2、擁有持久化的機(jī)制，進(jìn)程消息，隊列中的信息也可以保存下來。
3、實現(xiàn)消費(fèi)者和生產(chǎn)者之間的解耦。
4、對于高并發(fā)場景下，利用消息隊列可以使得同步訪問變?yōu)榇性L問達(dá)到一定量的限流，利于數(shù)據(jù)庫的操作。
5、可以使用消息隊列達(dá)到異步下單的效果，排隊中，后臺進(jìn)行邏輯下單。
3、使用rabbitmq的場景。
答：
1、服務(wù)間異步通信
2、順序消費(fèi)
3、定時任務(wù)
4、請求削峰
4、如何確保消息正確地發(fā)送至RabbitMQ？如何確保消息接收方消費(fèi)了消息？
答：
發(fā)送方確認(rèn)模式
1.將信道設(shè)置成confirm模式（發(fā)送方確認(rèn)模式），則所有在信道上發(fā)布的消息都會被指派一個唯一的ID。
2.一旦消息被投遞到目的隊列后，或者消息被寫入磁盤后（可持久化的消息），信道會發(fā)送一個確認(rèn)給生產(chǎn)者（包含消息唯一 ID）。
3.如果 RabbitMQ發(fā)生內(nèi)部錯誤從而導(dǎo)致消息丟失，會發(fā)送一條nack（notacknowledged，未確認(rèn)）消息。發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時，可以繼續(xù)發(fā)送消息。當(dāng)確認(rèn)消息到達(dá)生產(chǎn)者應(yīng)用程序，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會被觸發(fā)來處理確認(rèn)消息。
接收方確認(rèn)機(jī)制
接收方消息確認(rèn)機(jī)制
消費(fèi)者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個不同操作）。只有消費(fèi)者確認(rèn)了消息，RabbitMQ才能安全地把消息從隊列中刪除。這里并沒有用到超時機(jī)制，RabbitMQ僅通過Consumer的連接中斷來確認(rèn)是否需要重新發(fā)送消息。也就是說，只要連接不中斷，RabbitMQ給了Consumer足夠長的時間來處理消息。保證數(shù)據(jù)的最終一致性；
下面羅列幾種特殊情況
如果消費(fèi)者接收到消息，在確認(rèn)之前斷開了連接或取消訂閱，RabbitMQ會認(rèn)為消息沒有被分發(fā)，然后重新分發(fā)給下一個訂閱的消費(fèi)者。
（可能存在消息重復(fù)消費(fèi)的隱患，需要去重）如果消費(fèi)者接收到消息卻沒有確認(rèn)消息，連接也未斷開，則RabbitMQ認(rèn)為該消費(fèi)者繁忙，將不會給該消費(fèi)者分發(fā)更多的消息。
5.如何避免消息重復(fù)投遞或重復(fù)消費(fèi)？
答：
在消息生產(chǎn)時，MQ內(nèi)部針對每條生產(chǎn)者發(fā)送的消息生成一個inner-msg-id，作為去重的依據(jù)（消息投遞失敗并重傳），避免重復(fù)的消息進(jìn)入隊列；
在消息消費(fèi)時，要求消息體中必須要有一個 bizId（對于同一業(yè)務(wù)全局唯一，如支付ID、訂單ID、帖子ID 等）作為去重的依據(jù)，避免同一條消息被重復(fù)消費(fèi)。
6、消息基于什么傳輸？
答：
由于TCP連接的創(chuàng)建和銷毀開銷較大，且并發(fā)數(shù)受系統(tǒng)資源限制，會造成性能瓶頸。RabbitMQ使用信道的方式來傳輸數(shù)據(jù)。信道是建立在真實的TCP連接內(nèi)的虛擬連接，且每條TCP連接上的信道數(shù)量沒有限制
7、消息如何分發(fā)？
答：
若該隊列至少有一個消費(fèi)者訂閱，消息將以循環(huán)（round-robin）的方式發(fā)送給消費(fèi)者。每條消息只會分發(fā)給一個訂閱的消費(fèi)者（前提是消費(fèi)者能夠正常處理消息并進(jìn)行確認(rèn)）。
通過路由可實現(xiàn)多消費(fèi)的功能
8、消息怎么路由？
答：
消息提供方->路由->一至多個隊列
消息發(fā)布到交換器時，消息將擁有一個路由鍵（routing key），在消息創(chuàng)建時設(shè)定。
通過隊列路由鍵，可以把隊列綁定到交換器上。
消息到達(dá)交換器后，RabbitMQ 會將消息的路由鍵與隊列的路由鍵進(jìn)行匹配（針對不同的交換器有不同的路由規(guī)則）；
常用的交換器主要分為一下三種
1.fanout：如果交換器收到消息，將會廣播到所有綁定的隊列上
2.direct：如果路由鍵完全匹配，消息就被投遞到相應(yīng)的隊列
3.topic：可以使來自不同源頭的消息能夠到達(dá)同一個隊列。 使用topic交換器時，可以使用通配符
9、如何確保消息不丟失？
答：
消息持久化，當(dāng)然前提是隊列必須持久化
RabbitMQ確保持久性消息能從服務(wù)器重啟中恢復(fù)的方式是，將它們寫入磁盤上的一個持久化日志文件，當(dāng)發(fā)布一條持久性消息到持久交換器上時，Rabbit會在消息提交到日志文件后才發(fā)送響應(yīng)。
一旦消費(fèi)者從持久隊列中消費(fèi)了一條持久化消息，RabbitMQ會在持久化日志中把這條消息標(biāo)記為等待垃圾收集。如果持久化消息在被消費(fèi)之前RabbitMQ重啟，那么Rabbit會自動重建交換器和隊列（以及綁定），并重新發(fā)布持久化日志文件中的消息到合適的隊列。
10、使用RabbitMQ有什么好處？
答：
1、服務(wù)間高度解耦
2、異步通信性能高
3、流量削峰
11、RabbitMQ的集群。
答：
鏡像集群模式
你創(chuàng)建的queue，無論元數(shù)據(jù)還是queue里的消息都會存在于多個實例上，然后每次你寫消息到queue的時候，都會自動把消息到多個實例的queue里進(jìn)行消息同步。
好處在于，你任何一個機(jī)器宕機(jī)了，沒事兒，別的機(jī)器都可以用。壞處在于，第一，這個性能開銷也太大了吧，消息同步所有機(jī)器，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！第二，這么玩兒，就沒有擴(kuò)展性可言了，如果某個queue負(fù)載很重，你加機(jī)器，新增的機(jī)器也包含了這個queue的所有數(shù)據(jù)，并沒有辦法線性擴(kuò)展你的queue。
12、mq的缺點
答：
系統(tǒng)可用性降低
系統(tǒng)引入的外部依賴越多，越容易掛掉，本來你就是A系統(tǒng)調(diào)用BCD三個系統(tǒng)的接口就好了，人 ABCD四個系統(tǒng)好好的，沒啥問題，你偏加個MQ進(jìn)來，萬一MQ掛了咋整？MQ掛了，整套系統(tǒng)崩潰了，你不就完了么。
系統(tǒng)復(fù)雜性提高硬生生加個MQ進(jìn)來，你怎么保證消息沒有重復(fù)消費(fèi)？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
一致性問題
A系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統(tǒng)那里，BD兩個系統(tǒng)寫庫成功了，結(jié)果C系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致了。
所以消息隊列實際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方案和架構(gòu)來規(guī)避掉，最好之后，你會發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個數(shù)量級，也許是復(fù)雜了10倍。但是關(guān)鍵時刻，用，還是得用的。
13、什么是MQ ？
答：
MQ就是消息隊列。是軟件和軟件進(jìn)行通信的中間件產(chǎn)品。
14、MQ的優(yōu)點。
答：
簡答
異步處理 - 相比于傳統(tǒng)的串行、并行方式，提高了系統(tǒng)吞吐量。
應(yīng)用解耦 - 系統(tǒng)間通過消息通信，不用關(guān)心其他系統(tǒng)的處理。
流量削鋒 - 可以通過消息隊列長度控制請求量；可以緩解短時間內(nèi)的高并發(fā)請求。
日志處理 - 解決大量日志傳輸。
消息通訊 - 消息隊列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的消息通訊。比如實現(xiàn)點對點消息隊列，或者聊天室等。
15、解耦、異步、削峰是什么？
答：
解耦：A系統(tǒng)發(fā)送數(shù)據(jù)到BCD三個系統(tǒng)，通過接口調(diào)用發(fā)送。如果E系統(tǒng)也要這個數(shù)據(jù)呢？那如果C系統(tǒng)現(xiàn)在不需要了呢？A系統(tǒng)負(fù)責(zé)人幾乎崩潰A 系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，A系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)，很多系統(tǒng)都需要A系統(tǒng)將這個數(shù)據(jù)發(fā)送過來。如果使用MQ，A系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到MQ里面去，哪個系統(tǒng)需要數(shù)據(jù)自己去MQ里面消費(fèi)。如果新系統(tǒng)需要數(shù)據(jù)，直接從MQ里消費(fèi)即可；如果某個系統(tǒng)不需要這條數(shù)據(jù)了，就取消對MQ消息的消費(fèi)即可。這樣下來，A系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)，不需要維護(hù)這個代碼，也不需要考慮人家是否調(diào)用成功、失敗超時等情況。
就是一個系統(tǒng)或者一個模塊，調(diào)用了多個系統(tǒng)或者模塊，互相之間的調(diào)用很復(fù)雜，維護(hù)起來很麻煩。但是其 實這個調(diào)用是不需要直接同步調(diào)用接口的，如果用MQ給它異步化解耦。
異步：A系統(tǒng)接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統(tǒng)寫庫，自己本地寫庫要3ms，BCD三個系統(tǒng)分別寫庫要 300ms、450ms、200ms。最終請求總延時是3+300+450+200=953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發(fā)起請求。
如果使用MQ，那么A系統(tǒng)連續(xù)發(fā)送3條消息到MQ隊列中，假如耗時5ms，A系統(tǒng)從接受一個請求到返回響應(yīng)給用戶，總時長是3+5=8ms。
削峰：減少高峰時期對服務(wù)器壓力。
16、消息隊列有什么缺點？
答：
缺點有以下幾個：
本來系統(tǒng)運(yùn)行好好的，現(xiàn)在你非要加入個消息隊列進(jìn)去，那消息隊列掛了，你的系統(tǒng)不是呵呵了。因此，系統(tǒng)可用性會降低；
加入了消息隊列，要多考慮很多方面的問題，比如：一致性問題、如何保證消息不被重復(fù)消費(fèi)、如何保證消息可靠性傳輸?shù)取Ｒ虼?#xff0c;需要考慮的東西更多，復(fù)雜性增大。
A系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統(tǒng)那里，BD兩個系統(tǒng)寫庫成功了，結(jié)果C系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致了。
所以消息隊列實際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方 案和架構(gòu)來規(guī)避掉，做好之后，你會發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個數(shù)量級，也許是復(fù)雜了 10 倍。但是關(guān) 鍵時刻，用，還是得用的。
17、你們公司生產(chǎn)環(huán)境用的是什么消息中間件？
答：
這個首先你可以說下你們公司選用的是什么消息中間件，比如用的是RabbitMQ，然后可以初步給一些你對不同MQ中間件技術(shù)的選型分析。
舉個例子：比如說ActiveMQ是老牌的消息中間件，國內(nèi)很多公司過去運(yùn)用的還是非常廣泛的，功能很強(qiáng)大。
但是問題在于沒法確認(rèn)ActiveMQ可以支撐互聯(lián)網(wǎng)公司的高并發(fā)、高負(fù)載以及高吞吐的復(fù)雜場景，在國內(nèi)互聯(lián)網(wǎng)公司落地較少。而且使用較多的是一些傳統(tǒng)企業(yè)，用ActiveMQ做異步調(diào)用和系統(tǒng)解耦。
然后你可以說說RabbitMQ，他的好處在于可以支撐高并發(fā)、高吞吐、性能很高，同時有非常完善便捷的后臺管理界面可以使用。
另外，他還支持集群化、高可用部署架構(gòu)、消息高可靠支持，功能較為完善。
而且經(jīng)過調(diào)研，國內(nèi)各大互聯(lián)網(wǎng)公司落地大規(guī)模RabbitMQ集群支撐自身業(yè)務(wù)的case較多，國內(nèi)各種中小型互聯(lián)網(wǎng)公司使用RabbitMQ的實踐也比較多。
除此之外，RabbitMQ的開源社區(qū)很活躍，較高頻率的迭代版本，來修復(fù)發(fā)現(xiàn)的bug以及進(jìn)行各種優(yōu)化，因此綜合考慮過后，公司采取了RabbitMQ。
但是RabbitMQ也有一點缺陷，就是他自身是基于erlang語言開發(fā)的，所以導(dǎo)致較為難以分析里面的源碼，也較難進(jìn)行深層次的源碼定制和改造，畢竟需要較為扎實的erlang語言功底才可以。
然后可以聊聊RocketMQ，是阿里開源的，經(jīng)過阿里的生產(chǎn)環(huán)境的超高并發(fā)、高吞吐的考驗，性能卓越，同時還支持分布式事務(wù)等特殊場景。
而且RocketMQ是基于Java語言開發(fā)的，適合深入閱讀源碼，有需要可以站在源碼層面解決線上生產(chǎn)問題，包括源碼的二次開發(fā)和改造。
另外就是Kafka。Kafka提供的消息中間件的功能明顯較少一些，相對上述幾款MQ中間件要少很多。
但是Kafka的優(yōu)勢在于專為超高吞吐量的實時日志采集、實時數(shù)據(jù)同步、實時數(shù)據(jù)計算等場景來設(shè)計。
因此Kafka在大數(shù)據(jù)領(lǐng)域中配合實時計算技術(shù)（比如Spark Streaming、Storm、Flink）使用的較多。但是在傳統(tǒng)的MQ中間件使用場景中較少采用。
18、Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么優(yōu)缺點？
答：
綜上，各種對比之后，有如下建議：
一般的業(yè)務(wù)系統(tǒng)要引入MQ，最早大家都用ActiveMQ，但是現(xiàn)在確實大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
后來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的Java工程師去深入研究和掌控它，對公司而言，幾乎處于不可控的狀態(tài)，但是確實人家是開源的，比較穩(wěn)定的支持，活躍度也高；
不過現(xiàn)在確實越來越多的公司會去用RocketMQ，確實很不錯，畢竟是阿里出品，但社區(qū)可能有突然黃掉的風(fēng)險（目前 RocketMQ已捐給Apache，但GitHub上的活躍度其實不算高）對自己公司技術(shù)實力有絕對自信的，推薦用RocketMQ，否則回去老老實實用RabbitMQ 吧，人家有活躍的開源社區(qū)，絕對不會黃。
所以中小型公司，技術(shù)實力較為一般，技術(shù)挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎(chǔ)架構(gòu)研發(fā)實力較強(qiáng)，用 RocketMQ是很好的選擇。
如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范。
19、MQ有哪些常見問題？如何解決這些問題？
答：
MQ的常見問題有：
消息的順序問題
消息的重復(fù)問題
消息的順序問題
消息有序指的是可以按照消息的發(fā)送順序來消費(fèi)。
假如生產(chǎn)者產(chǎn)生了2條消息：M1、M2，假定 M1 發(fā)送到S1，M2 發(fā)送到S2，如果要保證 M1先于M2被消費(fèi)，怎么做？
解決方案：
缺陷：
并行度就會成為消息系統(tǒng)的瓶頸（吞吐量不夠）
更多的異常處理，比如：只要消費(fèi)端出現(xiàn)問題，就會導(dǎo)致整個處理流程阻塞，我們不得不花費(fèi)更多的精力來解決阻塞的問題。 （2）通過合理的設(shè)計或者將問題分解來規(guī)避。
不關(guān)注亂序的應(yīng)用實際大量存在
隊列無序并不意味著消息無序 所以從業(yè)務(wù)層面來保證消息的順序而不僅僅是依賴于消息系統(tǒng)，是一種更合理的方式。
消息的重復(fù)問題
造成消息重復(fù)的根本原因是：網(wǎng)絡(luò)不可達(dá)。
所以解決這個問題的辦法就是繞過這個問題。那么問題就變成了：如果消費(fèi)端收到兩條一樣的消息，應(yīng)該怎樣處理？
消費(fèi)端處理消息的業(yè)務(wù)邏輯保持冪等性。只要保持冪等性，不管來多少條重復(fù)消息，最后處理的結(jié)果都一樣。保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時出現(xiàn)。利用一張日志表來記錄已經(jīng)處理成功的消息的ID，如果新到的消息 ID已經(jīng)在日志表中，那么就不再處理這條消息。
20、RabbitMQ基本概念。
答：
Broker：簡單來說就是消息隊列服務(wù)器實體
Exchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個隊列
Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列
Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來
Routing Key： 路由關(guān)鍵字，exchange根據(jù)這個關(guān)鍵字進(jìn)行消息投遞
VHost：vhost可以理解為虛擬broker ，即mini-RabbitMQ server。其內(nèi)部均含有獨立的queue、exchange和binding等，但最最重要的是，其擁有獨立的權(quán)限系統(tǒng)，可以做到vhost范圍的用戶控制。當(dāng)然，從RabbitMQ的全局角度，vhost可以作為不同權(quán)限隔離的手段（一個典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）。
Producer： 消息生產(chǎn)者，就是投遞消息的程序
Consumer：消息消費(fèi)者，就是接受消息的程序
Channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務(wù)由Exchange、Queue、RoutingKey三個才能決定一個從Exchange到Queue的唯一的線路。
21、RabbitMQ的工作模式。
答：
一.simple模式（即最簡單的收發(fā)模式）
消息產(chǎn)生消息，將消息放入隊列
消息的消費(fèi)者(consumer) 監(jiān)聽 消息隊列,如果隊列中有消息,就消費(fèi)掉,消息被拿走后,自動從隊列中刪除(隱患 消息可能沒有被消費(fèi)者正確處理,已經(jīng)從隊列中消失了,造成消息的丟失，這里可以設(shè)置成手動的ack,但如果設(shè)置成手動ack，處理完后要及時發(fā)送ack消息給隊列，否則會造成內(nèi)存溢出)。
二.work工作模式(資源的競爭)
3.消息產(chǎn)生者將消息放入隊列消費(fèi)者可以有多個,消費(fèi)者1,消費(fèi)者2同時監(jiān)聽同一個隊列,消息被消費(fèi)。
4.C1 C2共同爭搶當(dāng)前的消息隊列內(nèi)容,誰先拿到誰負(fù)責(zé)消費(fèi)消息(隱患：高并發(fā)情況下,默認(rèn)會產(chǎn)生某一個消息被多個消費(fèi)者共同使用,可以設(shè)置一個開關(guān)(syncronize) 保證一條消息只能被一個消費(fèi)者使用)。
三.publish/subscribe發(fā)布訂閱(共享資源)
5.每個消費(fèi)者監(jiān)聽自己的隊列；
6.生產(chǎn)者將消息發(fā)給broker，由交換機(jī)將消息轉(zhuǎn)發(fā)到綁定此交換機(jī)的每個隊列，每個綁定交換機(jī)的隊列都將接收到消息。
四.routing路由模式
8. 消息生產(chǎn)者將消息發(fā)送給交換機(jī)按照路由判斷,路由是字符串(info) 當(dāng)前產(chǎn)生的消息攜帶路由字符(對象的方法),交換機(jī)根據(jù)路由的key,只能匹配上路由key對應(yīng)的消息隊列,對應(yīng)的消費(fèi)者才能消費(fèi)消息；
9.根據(jù)業(yè)務(wù)功能定義路由字符串；
10.從系統(tǒng)的代碼邏輯中獲取對應(yīng)的功能字符串,將消息任務(wù)扔到對應(yīng)的隊列中。
11.業(yè)務(wù)場景:error通知;EXCEPTION;錯誤通知的功能;傳統(tǒng)意義的錯誤通知;客戶通知;利用key路由,可以將程序中的錯誤封裝成消息傳入到消息隊列中,開發(fā)者可以自定義消費(fèi)者,實時接收錯誤; 五.topic 主題模式(路由模式的一種)
12. 星號井號代表通配符
13.星號代表多個單詞,井號代表一個單詞
14.路由功能添加模糊匹配
15.消息產(chǎn)生者產(chǎn)生消息,把消息交給交換機(jī)
16.交換機(jī)根據(jù)key的規(guī)則模糊匹配到對應(yīng)的隊列,由隊列的監(jiān)聽消費(fèi)者接收消息消費(fèi)（在我的理解看來就是routing查詢的一種模糊匹配，就類似sql的模糊查詢方式）
22、如何保證RabbitMQ消息的順序性？
答：
拆分多個queue(消息隊列)，每個queue(消息隊列) 一個consumer(消費(fèi)者)，就是多一些queue(消息隊列)而已，確實是麻煩點；
或者就一個queue (消息隊列)但是對應(yīng)一個consumer(消費(fèi)者)，然后這個consumer(消費(fèi)者)內(nèi)部用內(nèi)存隊列做排隊，然后分發(fā)給底層不同的worker來處理。
23、消息如何分發(fā)？
答：
若該隊列至少有一個消費(fèi)者訂閱，消息將以循環(huán)（round-robin）的方式發(fā)送給消費(fèi)者。每條消息只會分發(fā)給一個訂閱的消費(fèi)者（前提是消費(fèi)者能夠正常處理消息并進(jìn)行確認(rèn)）。通過路由可實現(xiàn)多消費(fèi)的功能。
24、消息怎么路由？
答：
消息提供方->路由->一至多個隊列消息發(fā)布到交換器時，消息將擁有一個路由鍵（routing key），在消息創(chuàng)建時設(shè)定。通過隊列路由鍵，可以把隊列綁定到交換器上。消息到達(dá)交換器后，RabbitMQ 會將消息的路由鍵與隊列的路由鍵進(jìn)行匹配（針對不同的交換器有不同的路由規(guī)則）；
常用的交換器主要分為一下三種：
fanout：如果交換器收到消息，將會廣播到所有綁定的隊列上
direct：如果路由鍵完全匹配，消息就被投遞到相應(yīng)的隊列
topic：可以使來自不同源頭的消息能夠到達(dá)同一個隊列。 使用 topic 交換器時，可以使用通配符
25、消息基于什么傳輸？
答：
由于 TCP 連接的創(chuàng)建和銷毀開銷較大，且并發(fā)數(shù)受系統(tǒng)資源限制，會造成性能瓶頸。RabbitMQ使用信道的方式來傳輸數(shù)據(jù)。信道是建立在真實的 TCP 連接內(nèi)的虛擬連接，且每條 TCP 連接上的信道數(shù)量沒有限制。
26、如何保證消息不被重復(fù)消費(fèi)？或者說，如何保證消息消費(fèi)時的冪等性？
答：
先說為什么會重復(fù)消費(fèi)：正常情況下，消費(fèi)者在消費(fèi)消息的時候，消費(fèi)完畢后，會發(fā)送一個確認(rèn)消息給消息隊列，消息隊列就知道該消息被消費(fèi)了，就會將該消息從消息隊列中刪除；
但是因為網(wǎng)絡(luò)傳輸?shù)鹊裙收?#xff0c;確認(rèn)信息沒有傳送到消息隊列，導(dǎo)致消息隊列不知道自己已經(jīng)消費(fèi)過該消息了，再次將消息分發(fā)給其他的消費(fèi)者。
針對以上問題，一個解決思路是：保證消息的唯一性，就算是多次傳輸，不要讓消息的多次消費(fèi)帶來影響；保證消息等冪性；
比如：在寫入消息隊列的數(shù)據(jù)做唯一標(biāo)示，消費(fèi)消息時，根據(jù)唯一標(biāo)識判斷是否消費(fèi)過；
假設(shè)你有個系統(tǒng)，消費(fèi)一條消息就往數(shù)據(jù)庫里插入一條數(shù)據(jù)，要是你一個消息重復(fù)兩次，你不就插入了兩條，這數(shù)據(jù)不就錯了？但是你要是消費(fèi)到第二次的時候，自己判斷一下是否已經(jīng)消費(fèi)過了，若是就直接扔了，這樣不就保留了一條數(shù)據(jù)，從而保證了數(shù)據(jù)的正確性。
27、如何確保消息正確地發(fā)送至 RabbitMQ？ 如何確保消息接收方消費(fèi)了消息？
答：
發(fā)送方確認(rèn)模式
將信道設(shè)置成confirm模式（發(fā)送方確認(rèn)模式），則所有在信道上發(fā)布的消息都會被指派一個唯一的ID。
一旦消息被投遞到目的隊列后，或者消息被寫入磁盤后（可持久化的消息），信道會發(fā)送一個確認(rèn)給生產(chǎn)者（包含消息唯一 ID）如果RabbitMQ發(fā)生內(nèi)部錯誤從而導(dǎo)致消息丟失，會發(fā)送一條nack（notacknowledged，未確認(rèn)）消息。
發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時，可以繼續(xù)發(fā)送消息。當(dāng)確認(rèn)消息到達(dá)生產(chǎn)者應(yīng)用程序，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會被觸發(fā)來處理確認(rèn)消息。
接收方確認(rèn)機(jī)制消費(fèi)者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個不同操作）。只有消費(fèi)者確
認(rèn)了消息，RabbitMQ才能安全地把消息從隊列中刪除。
這里并沒有用到超時機(jī)制，RabbitMQ僅通過Consumer的連接中斷來確認(rèn)是否需要重新發(fā)送消息。也就是說，只要連接不中斷，RabbitMQ給了Consumer足夠長的時間來處理消息。保證數(shù)據(jù)的最終一致性；
下面羅列幾種特殊情況
如果消費(fèi)者接收到消息，在確認(rèn)之前斷開了連接或取消訂閱，RabbitMQ 會認(rèn)為消息沒有被分發(fā)，然后重新分發(fā)給下一個訂閱的消費(fèi)者。（可能存在消息重復(fù)消費(fèi)的隱患，需要去重）如果消費(fèi)者接收到消息卻沒有確認(rèn)消息，連接也未斷開，則RabbitMQ認(rèn)為該消費(fèi)者繁忙，將不會給該消費(fèi)者分發(fā)更多的消息。
28、如何保證RabbitMQ消息的可靠傳輸？
答：
消息不可靠的情況可能是消息丟失，劫持等原因；
丟失又分為：生產(chǎn)者丟失消息、消息列表丟失消息、消費(fèi)者丟失消息；
transaction機(jī)制就是說：發(fā)送消息前，開啟事務(wù)（channel.txSelect()）,然后發(fā)送消息，如果發(fā)送過程中出現(xiàn)什么異常，事務(wù)就會回滾（channel.txRollback()）,如果發(fā)送成功則提交事務(wù)（channel.txCommit()）。然而，這種方式有個缺點：吞吐量下降；
confirm模式用的居多：一旦channel進(jìn)入confirm模式，所有在該信道上發(fā)布的消息都將會被指派一個唯一的ID（從1開始），一旦消息被投遞到所有匹配的隊列之后；
rabbitMQ就會發(fā)送一個ACK給生產(chǎn)者（包含消息的唯一ID），這就使得生產(chǎn)者知道消息已經(jīng)正確到達(dá)目的隊列了；
如果rabbitMQ沒能處理該消息，則會發(fā)送一個Nack消息給你，你可以進(jìn)行重試操作。
處理消息隊列丟數(shù)據(jù)的情況，一般是開啟持久化磁盤的配置。
這個持久化配置可以和confirm機(jī)制配合使用，你可以在消息持久化磁盤后，再給生產(chǎn)者發(fā)送一個Ack信號。
這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那么生產(chǎn)者收不到Ack信號，生產(chǎn)者會自動重發(fā)。
那么如何持久化呢？
這里順便說一下吧，其實也很容易，就下面兩步
2.發(fā)送消息的時候?qū)eliveryMode=2這樣設(shè)置以后，即使rabbitMQ掛了，重啟后也能恢復(fù)數(shù)據(jù)
3.消費(fèi)者丟失消息：消費(fèi)者丟數(shù)據(jù)一般是因為采用了自動確認(rèn)消息模式，改為手動確認(rèn)消息即可！
消費(fèi)者在收到消息之后，處理消息之前，會自動回復(fù)RabbitMQ已收到消息；
如果這時處理消息失敗，就會丟失該消息；
解決方案：處理消息成功后，手動回復(fù)確認(rèn)消息。
29、為什么不應(yīng)該對所有的message都使用持久化機(jī)制？
答：
首先，必然導(dǎo)致性能的下降，因為寫磁盤比寫RAM慢的多，message的吞吐量可能有10倍的差距。
其次，message的持久化機(jī)制用在RabbitMQ的內(nèi)置cluster方案時會出現(xiàn)“坑爹”問題。矛盾點在于，若message設(shè)置了persistent屬性，但queue未設(shè)置durable屬性，那么當(dāng)該queue的owner node出現(xiàn)異常后，在未重建該queue前，發(fā)往該queue 的message將被 blackholed；若 message 設(shè)置了 persistent屬性，同時queue也設(shè)置了durable屬性，那么當(dāng)queue的owner node異常且無法重啟的情況下，則該queue無法在其他node上重建，只能等待其owner node重啟后，才能恢復(fù)該 queue的使用，而在這段時間內(nèi)發(fā)送給該queue的message將被 blackholed 。
所以，是否要對message進(jìn)行持久化，需要綜合考慮性能需要，以及可能遇到的問題。若想達(dá)到100,000 條/秒以上的消息吞吐量（單RabbitMQ服務(wù)器），則要么使用其他的方式來確保message的可靠delivery ，要么使用非常快速的存儲系統(tǒng)以支持全持久化（例如使用SSD）。
另外一種處理原則是：僅對關(guān)鍵消息作持久化處理（根據(jù)業(yè)務(wù)重要程度），且應(yīng)該保證關(guān)鍵消息的量不會導(dǎo)致性能瓶頸。
30、如何保證高可用的？RabbitMQ的集群？
答：
RabbitMQ是比較有代表性的，因為是基于主從（非分布式）做高可用性的，我們就以RabbitMQ為例子講解第一種MQ的高可用性怎么實現(xiàn)。RabbitMQ有三種模式：單機(jī)模式、普通集群模式、鏡像集群模式。
單機(jī)模式，就是Demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產(chǎn)用單機(jī)模式
普通集群模式：
意思就是在多臺機(jī)器上啟動多個RabbitMQ實例，每個機(jī)器啟動一個。
你創(chuàng)建的queue，只會放在一個RabbitMQ實例上，但是每個實例都同步queue的元數(shù)據(jù)（元數(shù)據(jù)可以認(rèn)為是queue的一些配置信息，通過元數(shù)據(jù)，可以找到queue所在實例）。
你消費(fèi)的時候，實際上如果連接到了另外一個實例，那么那個實例會從queue所在實例上拉取數(shù)據(jù)過來。這方案主要是提高吞吐量的，就是說讓集群中多個節(jié)點來服務(wù)某個queue的讀寫操作。
這種模式，才是所謂的RabbitMQ的高可用模式。跟普通集群模式不一樣的是，在鏡像集群模式下，你創(chuàng)建的queue，無論元數(shù)據(jù)還是 queue 里的消息都會存在于多個實例上，就是說，每個RabbitMQ節(jié)點都有這個queue的一個完整鏡像，包含queue的全部數(shù)據(jù)的意思。然后每次你寫消息到queue的時候，都會自動把消息同步到多個實例的queue上。
RabbitMQ有很好的管理控制臺，就是在后臺新增一個策略，這個策略是鏡像集群模式的策略，指定的時候是可以要求數(shù)據(jù)同步到所有節(jié)點的，也可以要求同步到指定數(shù)量的節(jié)點，再次創(chuàng)建queue的時候，應(yīng)用這個策略，就會自動將數(shù)據(jù)同步到其他的節(jié)點上去了。
這樣的好處在于，你任何一個機(jī)器宕機(jī)了，沒事兒，其它機(jī)器（節(jié)點）還包含了這個queue的完整數(shù)據(jù)，別的consumer都可以到其它節(jié)點上去消費(fèi)數(shù)據(jù)。壞處在于，第一，這個性能開銷也太大了吧，消息需要同步到所有機(jī)器上，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！RabbitMQ一個queue的數(shù)據(jù)都是放在一個節(jié)點里的，鏡像集群下，也是每個節(jié)點都放這個queue的完整數(shù)據(jù)。
31、如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續(xù)積壓幾小時，怎么辦？
答：
消息積壓處理辦法：臨時緊急擴(kuò)容：
先修復(fù)consumer的問題，確保其恢復(fù)消費(fèi)速度，然后將現(xiàn)有cnosumer都停掉。
新建一個topic，partition是原來的10倍，臨時建立好原先10倍的queue數(shù)量。
然后寫一個臨時的分發(fā)數(shù)據(jù)的consumer程序，這個程序部署上去消費(fèi)積壓的數(shù)據(jù)，消費(fèi)之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的10倍數(shù)量的queue。
接著臨時征用10倍的機(jī)器來部署consumer，每一批consumer消費(fèi)一個臨時queue的數(shù)據(jù)。這種做法相當(dāng)于是臨時將 queue 資源和consumer資源擴(kuò)大10倍，以正常的10倍速度來消費(fèi)數(shù)據(jù)。
等快速消費(fèi)完積壓數(shù)據(jù)之后，得恢復(fù)原先部署的架構(gòu)，重新用原先的consumer機(jī)器來消費(fèi)消息。
MQ中消息失效：假設(shè)你用的是RabbitMQ，RabbtiMQ是可以設(shè)置過期時間的，也就是 TTL。如果消息在queue中積壓超過一定的時間就會被RabbitMQ給清理掉，這個數(shù)據(jù)就沒了。那這就是第二個坑了。
這就不是說數(shù)據(jù)會大量積壓在mq里，而是大量的數(shù)據(jù)會直接搞丟。我們可以采取一個方案，就是批量重導(dǎo)，這個我們之前線上也有類似的場景干過。就是大量積壓的時候，我們當(dāng)時就直接丟棄數(shù)據(jù)了，然后等過了高峰期以后，比如大家一起喝咖啡熬夜到晚上12點以后，用戶都睡覺了。這個時候我們就開始寫程序，將丟失的那批數(shù)據(jù)，寫個臨時程序，一點一點的查出來，
然后重新灌入mq里面去，把白天丟的數(shù)據(jù)給他補(bǔ)回來。也只能是這樣了。假設(shè)1萬個訂單積壓在mq里面，沒有處理，其中 1000個訂單都丟了，你只能手動寫程序把那1000個訂單給查出來，手動發(fā)到mq里去再補(bǔ)一次。
mq消息隊列塊滿了：如果消息積壓在mq里，你很長時間都沒有處理掉，此時導(dǎo)致mq都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執(zhí)行的太慢了，你臨時寫程序，接入數(shù)據(jù)來消費(fèi)，消費(fèi)一個丟棄一個，都不要了，快速消費(fèi)掉所有的消息。然后走第二個方案，到了晚上再補(bǔ)數(shù)據(jù)吧。
32、設(shè)計MQ思路。
答：
比如說這個消息隊列系統(tǒng)，我們從以下幾個角度來考慮一下：
首先這個mq得支持可伸縮性吧，就是需要的時候快速擴(kuò)容，就可以增加吞吐量和容量，那怎么搞？設(shè)計個分布式的系統(tǒng)唄，參照一下kafka的設(shè)計理念，broker->topic->partition，每個partition放一個機(jī)器，就存一部分?jǐn)?shù)據(jù)。如果現(xiàn)在資源不夠了，簡單啊，給topic增加partition，然后做數(shù)據(jù)遷移，增加機(jī)器，不就可以存放更多數(shù)據(jù)，提供更高的吞吐量了？
其次你得考慮一下這個mq的數(shù)據(jù)要不要落地磁盤吧？那肯定要了，落磁盤才能保證別進(jìn)程掛了數(shù)據(jù)就丟了。那落磁盤的時候怎么落啊？順序?qū)?#xff0c;這樣就沒有磁盤隨機(jī)讀寫的尋址開銷，磁盤順序讀寫的性能是很高的，這就是 kafka 的思路。
其次你考慮一下你的mq的可用性啊？這個事兒，具體參考之前可用性那個環(huán)節(jié)講解的kafka的高可用保障機(jī)制。多副本 -> leader&follower->broker掛了重新選舉 leader 即可對外服務(wù)。能不能支持?jǐn)?shù)據(jù)0丟失啊？可以呀，有點復(fù)雜的。
總結(jié)
該面試題答案解析完整文檔獲取方式：RabbitMQ面試題總結(jié)
先自我介紹一下，小編13年上師交大畢業(yè)，曾經(jīng)在小公司待過，去過華為OPPO等大廠，18年進(jìn)入阿里，直到現(xiàn)在。深知大多數(shù)初中級java工程師，想要升技能，往往是需要自己摸索成長或是報班學(xué)習(xí)，但對于培訓(xùn)機(jī)構(gòu)動則近萬元的學(xué)費(fèi)，著實壓力不小。自己不成體系的自學(xué)效率很低又漫長，而且容易碰到天花板技術(shù)停止不前。因此我收集了一份《java開發(fā)全套學(xué)習(xí)資料》送給大家，初衷也很簡單，就是希望幫助到想自學(xué)又不知道該從何學(xué)起的朋友，同時減輕大家的負(fù)擔(dān)。添加下方名片，即可獲取全套學(xué)習(xí)資料哦
總結(jié)
以上是生活随笔為你收集整理的【2021最新版】RabbitMQ面试题总结（32道题含答案解析）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 双系统 移动硬盘安装Ubuntu详细流程
- 下一篇： 刻录服务器系统光盘,系统光盘制作