大家對(duì)RabbitMQ原理都應(yīng)該有所了解，下面我們就來看一下關(guān)于RabbitMQ原理的面試題。

1.為什么要引入MQ系統(tǒng)，直接讀寫數(shù)據(jù)庫不行嗎?

其實(shí)就是問問你消息隊(duì)列都有哪些使用場(chǎng)景，然后你項(xiàng)目里具體是什么場(chǎng)景，說說你在這個(gè)場(chǎng)景里用消息隊(duì)列是什么?

先說一下消息隊(duì)列常見的使用場(chǎng)景吧，其實(shí)場(chǎng)景有很多，但是比較核心的有 3 個(gè)：解耦、異步、削峰。

解耦：多系統(tǒng)多進(jìn)程的數(shù)據(jù)交換，用pub/sub

異步：把大數(shù)據(jù)量的同步處理改為異步

削峰：一般的A 系統(tǒng)使用 MySQL，扛到每秒 2k 個(gè)請(qǐng)求就差不多了，如果每秒請(qǐng)求到 5k 的話，可能就直接把 MySQL 給打死了，導(dǎo)致系統(tǒng)崩潰，用戶也就沒法再使用系統(tǒng)了。如果使用 MQ， 每秒 5k 個(gè)請(qǐng)求寫入 MQ，A 系統(tǒng)每秒鐘最多處理 2k 個(gè)請(qǐng)求，因?yàn)?MySQL 每秒鐘最多處理 2k 個(gè)。A 系統(tǒng)從 MQ 中慢慢拉取請(qǐng)求，每秒鐘就拉取 2k 個(gè)請(qǐng)求，不要超過自己每秒能處理的最 大請(qǐng)求數(shù)量就 ok，這樣下來，哪怕是高峰期的時(shí)候，A 系統(tǒng)也絕對(duì)不會(huì)掛掉，這又設(shè)計(jì)請(qǐng)求排隊(duì)的問題。

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

優(yōu)點(diǎn)：解耦、異步、削峰

缺點(diǎn)：

系統(tǒng)可用性降低

系統(tǒng)引入的外部依賴越多，越容易掛掉。

系統(tǒng)復(fù)雜度提高

一致性問題

A 系統(tǒng)處理完了直接返回成功了，人都以為你這個(gè)請(qǐng)求就成功了;但是問題是，要是 BCD 三個(gè)系統(tǒng)那里，BD 兩個(gè)系統(tǒng)寫庫成功了，結(jié)果 C 系統(tǒng)寫庫失敗了，這數(shù)據(jù)就不一致了。

3.RabbitMQ 的高可用性如何保證?

RabbitMQ 有三種模式：?jiǎn)螜C(jī)模式、普通集群模式、鏡像集群模式

單機(jī)模式不存在高可用。

普通集群模式也不存在高可用性，意思就是在多臺(tái)機(jī)器上啟動(dòng)多個(gè) RabbitMQ 實(shí)例，每個(gè)機(jī)器啟動(dòng)一個(gè)。但是你創(chuàng)建的 queue，只會(huì)放在一個(gè) RabbitMQ 實(shí)例上，但是每個(gè)實(shí)例都同步 queue 的元數(shù)據(jù)(元數(shù)據(jù)可以認(rèn)為是 queue 的一些配置信息，通過元數(shù)據(jù)，可以找到 queue 所在實(shí)例)。你消費(fèi)的時(shí)候，實(shí)際上如果連接到了另外一個(gè)實(shí)例，那么那個(gè)實(shí)例會(huì)從 queue 所在實(shí)例上 拉取數(shù)據(jù)過來。這種方式確實(shí)很麻煩，也不怎么好，沒做到所謂的分布式，就是個(gè)普通集群。因?yàn)檫@導(dǎo)致你要么消費(fèi)者每次隨機(jī)連接一個(gè)實(shí)例然后拉取數(shù)據(jù)，要么固定連接那個(gè) queue 所在實(shí) 例消費(fèi)數(shù)據(jù)，前者有數(shù)據(jù)拉取的開銷，后者導(dǎo)致單實(shí)例性能瓶頸。而且如果那個(gè)放 queue 的實(shí)例宕機(jī)了，會(huì)導(dǎo)致接下來其他實(shí)例就無法從那個(gè)實(shí)例拉取，如果你開啟了消息持久化，讓 RabbitMQ 落地存儲(chǔ)消息的話，消息不一定會(huì)丟，得等這個(gè)實(shí)例恢復(fù)了，然后才可以繼續(xù)從這個(gè) queue 拉取數(shù)據(jù)。

鏡像集群模式的策略是高可用策略，指定的時(shí)候可以要求數(shù)據(jù)同步到所有節(jié)點(diǎn)的，也可以要求同步到指定數(shù)量的節(jié)點(diǎn)，再次創(chuàng)建 queue 的時(shí)候，應(yīng)用這個(gè)策略，就會(huì)自動(dòng)將數(shù)據(jù)同步到其他的 節(jié)點(diǎn)上去了。

4.如何解決消息隊(duì)列的延時(shí)以及過期失效問題?

其實(shí)本質(zhì)針對(duì)的場(chǎng)景，都是說，可能你的消費(fèi)端出了問題，不消費(fèi)了;或者消費(fèi)的速度極其慢，造成消息堆積了，MQ存儲(chǔ)快要爆了，甚至開始過期失效刪除數(shù)據(jù)了。

針對(duì)這個(gè)問題可以有事前、事中、事后三種處理

事前：開發(fā)預(yù)警程序，監(jiān)控最大的可堆積消息數(shù)，超過就發(fā)預(yù)警消息(比如短信)，不要等出生產(chǎn)事故了再處理。

事中：看看消費(fèi)端是不是故障停止了，緊急重啟。

事后：需要對(duì)消費(fèi)端緊急擴(kuò)容 ，增加處理消費(fèi)者進(jìn)程，如擴(kuò)充10倍處理，但其實(shí)這也有個(gè)問題，即數(shù)據(jù)庫的吞吐是有限制的，如果是消費(fèi)到數(shù)據(jù)庫也是沒辦法巨量擴(kuò)容的，所以還是要在吞吐能力支持下老老實(shí)實(shí)的泄洪消 費(fèi)。所以事前預(yù)防還是最重要的。否則出發(fā)刪除過期數(shù)據(jù)，那就需要再重寫生產(chǎn)消息的程序，重新產(chǎn)生消息。

5.RabbitMQ如何保證不丟數(shù)據(jù)?

需要考慮3個(gè)可能丟數(shù)據(jù)的地方：生產(chǎn)端、隊(duì)列本身、消費(fèi)端

(1)生產(chǎn)端：開啟事務(wù)(不推薦，太耗性能降低吞吐)，推薦開啟 confirm 模式，在生產(chǎn)者那里設(shè)置開啟 confirm 模式之后，你每次寫的消息都會(huì)分配一個(gè)唯一的 id，然后如果寫入了RabbitMQ 中，RabbitMQ 會(huì)給你回傳一個(gè) ack 消息，告訴你說這個(gè)消息 ok 了。如果 RabbitMQ 沒能處理這個(gè)消息，會(huì)回調(diào)你的一個(gè) nack 接口，告訴你這個(gè)消息接收失敗，你可以重試。而 且你可以結(jié)合這個(gè)機(jī)制自己在內(nèi)存里維護(hù)每個(gè)消息 id 的狀態(tài)，如果超過一定時(shí)間還沒接收到這個(gè)消息的回調(diào)，那么你可以重發(fā)。

(2)隊(duì)列本身：就是 RabbitMQ 自己弄丟了數(shù)據(jù)，這個(gè)你必須開啟 RabbitMQ 的持久化，就是消息寫入之后會(huì)持久化到磁盤，哪怕是 RabbitMQ 自己掛了，恢復(fù)之后會(huì)自動(dòng)讀取之前存儲(chǔ)的數(shù)據(jù)，一般數(shù)據(jù)不會(huì)丟。

設(shè)置持久化有兩個(gè)步驟：

創(chuàng)建 queue 的時(shí)候?qū)⑵湓O(shè)置為持久化，這樣就可以保證 RabbitMQ 持久化 queue 的元數(shù)據(jù)，但是它是不會(huì)持久化 queue 里的數(shù)據(jù)的。

第二個(gè)是發(fā)送消息的時(shí)候?qū)⑾⒌?deliveryMode 設(shè)置為 2。就是將消息設(shè)置為持久化的，此時(shí) RabbitMQ 就會(huì)將消息持久化到磁盤上去。

(3)消費(fèi)端：其實(shí)和kafka的原理很類似，kafka即手動(dòng)提交offsize。用RabbitMQ 提供的 ack 機(jī)制，簡(jiǎn)單來說，就是你必須關(guān)閉 RabbitMQ 的自動(dòng) ack，通過自己的一個(gè) api 來調(diào)用就行，然后每次你自己代碼里確保處理完的時(shí)候，再在程序里 ack。這樣的話，如果你還沒處理完，不就沒有 ack 了?那 RabbitMQ 就認(rèn)為你還沒處理完，這個(gè)時(shí)候 RabbitMQ 會(huì)把這個(gè)消費(fèi)分配給別 的 consumer 去處理，消息是不會(huì)丟的。

6.如何保證隊(duì)列的消息不被重復(fù)消費(fèi)?

這個(gè)需要靈活作答，考察的是思考力，因?yàn)橄M(fèi)的場(chǎng)景有很多，有數(shù)據(jù)庫、有緩存、有第三方接口

(1)比如針對(duì)數(shù)據(jù)庫，你拿到這個(gè)消息做數(shù)據(jù)庫的insert操作。那就容易了，給這個(gè)消息做一個(gè)唯一主鍵(或者UUID)，那么就算出現(xiàn)重復(fù)消費(fèi)的情況，就會(huì)導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫出現(xiàn)臟數(shù)據(jù)。

(2)再比如redis緩存，你拿到這個(gè)消息做redis的set的操作，那就容易了，不用解決，因?yàn)槟銦o論set幾次結(jié)果都是一樣的，set操作本來就算冪等操作。

(3)再比如第三方接口，需要確定兩點(diǎn)，第三方接口程序是有去重能力的，那么臟一點(diǎn)直接丟數(shù)據(jù)過去，如果沒有去重能力，還是需要我們來寫程序去重，就是第2點(diǎn)的辦法。

7.集群節(jié)點(diǎn)類型都有什么?

節(jié)點(diǎn)的存儲(chǔ)類型分為兩種：

磁盤節(jié)點(diǎn)

內(nèi)存節(jié)點(diǎn)

磁盤節(jié)點(diǎn)就是配置信息和元信息存儲(chǔ)在磁盤上，內(nèi)存節(jié)點(diǎn)把這些信息存儲(chǔ)在內(nèi)存中，當(dāng)然內(nèi)次節(jié)點(diǎn)的性能是大大超越磁盤節(jié)點(diǎn)的。

單節(jié)點(diǎn)系統(tǒng)必須是磁盤節(jié)點(diǎn)，否則每次你重啟RabbitMQ之后所有的系統(tǒng)配置信息都會(huì)丟失。

RabbitMQ要求集群中至少有一個(gè)磁盤節(jié)點(diǎn)，當(dāng)節(jié)點(diǎn)加入和離開集群時(shí)，必須通知磁盤節(jié)點(diǎn)。

以上就是關(guān)于“RabbitMQ原理面試題”的介紹，你都答對(duì)了嗎？如果還想了解更多相關(guān)知識(shí)，可以關(guān)注一下動(dòng)力節(jié)點(diǎn)RabbitMQ教程。教程內(nèi)容由淺到深，細(xì)致全面，當(dāng)然也有配套的視頻教程供可以免費(fèi)下載學(xué)習(xí)，希望對(duì)大家能夠有所幫助。