（1）為什么使用消息隊列?。?br>

其實就是問問你消息隊列都有哪些使用場景，然后你項目里具體是什么場景，說說你在這個場景里用消息隊列是什么

面試官問你這個問題，期望的一個回答是說，你們公司有個什么業(yè)務(wù)場景，這個業(yè)務(wù)場景有個什么技術(shù)挑戰(zhàn)，如果不用MQ可能會很麻煩，但是你現(xiàn)在用了MQ之后帶給了你很多的好處

先說一下消息隊列的常見使用場景吧，其實場景有很多，但是比較核心的有3個：解耦、異步、削峰

解耦：現(xiàn)場畫個圖來說明一下，A系統(tǒng)發(fā)送個數(shù)據(jù)到BCD三個系統(tǒng)，接口調(diào)用發(fā)送，那如果E系統(tǒng)也要這個數(shù)據(jù)呢？那如果C系統(tǒng)現(xiàn)在不需要了呢？現(xiàn)在A系統(tǒng)又要發(fā)送第二種數(shù)據(jù)了呢？A系統(tǒng)負(fù)責(zé)人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統(tǒng)要時時刻刻考慮BCDE四個系統(tǒng)如果掛了咋辦？我要不要重發(fā)？我要不要把消息存起來？頭發(fā)都白了啊。。。

面試技巧：你需要去考慮一下你負(fù)責(zé)的系統(tǒng)中是否有類似的場景，就是一個系統(tǒng)或者一個模塊，調(diào)用了多個系統(tǒng)或者模塊，互相之間的調(diào)用很復(fù)雜，維護起來很麻煩。但是其實這個調(diào)用是不需要直接同步調(diào)用接口的，如果用MQ給他異步化解耦，也是可以的，你就需要去考慮在你的項目里，是不是可以運用這個MQ去進行系統(tǒng)的解耦。在簡歷中體現(xiàn)出來這塊東西，用MQ作解耦。

異步：現(xiàn)場畫個圖來說明一下，A系統(tǒng)接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統(tǒng)寫庫，自己本地寫庫要3ms，BCD三個系統(tǒng)分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。

削峰：每天0點到11點，A系統(tǒng)風(fēng)平浪靜，每秒并發(fā)請求數(shù)量就100個。結(jié)果每次一到11點~1點，每秒并發(fā)請求數(shù)量突然會暴增到1萬條。但是系統(tǒng)最大的處理能力就只能是每秒鐘處理1000個請求啊。。。尷尬了，系統(tǒng)會死。。。

（2）消息隊列有什么優(yōu)點和缺點??？

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

缺點呢？顯而易見的

系統(tǒng)可用性降低：系統(tǒng)引入的外部依賴越多，越容易掛掉，本來你就是A系統(tǒng)調(diào)用BCD三個系統(tǒng)的接口就好了，人ABCD四個系統(tǒng)好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統(tǒng)崩潰了，你不就完了么。

系統(tǒng)復(fù)雜性提高：硬生生加個MQ進來，你怎么保證消息沒有重復(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)鍵時刻，用，還是得用的。。。

（3）kafka、activemq、rabbitmq、rocketmq都有什么優(yōu)點和缺點啊？

常見的MQ其實就這幾種，別的還有很多其他MQ，但是比較冷門的，那么就別多說了

綜上所述，各種對比之后，我個人傾向于是：

一般的業(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)險，對自己公司技術(shù)實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人是活躍開源社區(qū)，絕對不會黃

所以中小型公司，技術(shù)實力較為一般，技術(shù)挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎(chǔ)架構(gòu)研發(fā)實力較強，用RocketMQ是很好的選擇

如果是大數(shù)據(jù)領(lǐng)域的實時計算、日志采集等場景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領(lǐng)域的事實性規(guī)范

1、面試題

如何保證消息隊列的高可用??？

2、面試官心理分析

如果有人問到你MQ的知識，高可用是必問的，因為MQ的缺點，我剛才已經(jīng)說過了，有好多，導(dǎo)致系統(tǒng)可用性降低，等等。所以只要你用了MQ，接下來問的一些要點肯定就是圍繞著MQ的那些缺點怎么來解決了。

要是你傻乎乎的就干用了一個MQ，各種問題從來沒考慮過，那你就杯具了，面試官對你的印象就是，只會簡單實用一些技術(shù)，沒任何思考，馬上對你的印象就不太好了。這樣的同學(xué)招進來要是做個20k薪資以內(nèi)的普通小弟還湊合。如果招進來做薪資20多k的高工，那就慘了，讓你設(shè)計個系統(tǒng)，里面肯定一堆坑，出了事故公司受損失，團隊一起背鍋。

去年的事兒，非常大的互聯(lián)網(wǎng)公司，非常核心的系統(tǒng)，就是疏忽了MQ，沒考慮MQ如何保證高可用，如果MQ掛了怎么辦，導(dǎo)致幾個小時系統(tǒng)不可用，公司損失幾千萬，team背鍋，你鬧的禍，你老大幫你一起背鍋

3、面試題剖析

這個問題這么問是很好的，因為不能問你kafka的高可用性怎么保證??？ActiveMQ的高可用性怎么保證??？一個面試官要是這么問就顯得很沒水平，人家可能用的就是RabbitMQ，沒用過Kafka，你上來問人家kafka干什么？這不是擺明了刁難人么。

所以有水平的面試官，問的是MQ的高可用性怎么保證？這樣就是你用過哪個MQ，你就說說你對那個MQ的高可用性的理解。

（1）RabbitMQ的高可用性

RabbitMQ是比較有代表性的，因為是基于主從做高可用性的，我們就以他為例子講解第一種MQ的高可用性怎么實現(xiàn)。

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

1）單機模式

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

2）普通集群模式

意思就是在多臺機器上啟動多個rabbitmq實例，每個機器啟動一個。但是你創(chuàng)建的queue，只會放在一個rabbtimq實例上，但是每個實例都同步queue的元數(shù)據(jù)。完了你消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從queue所在實例上拉取數(shù)據(jù)過來。

這種方式確實很麻煩，也不怎么好，沒做到所謂的分布式，就是個普通集群。因為這導(dǎo)致你要么消費者每次隨機連接一個實例然后拉取數(shù)據(jù)，要么固定連接那個queue所在實例消費數(shù)據(jù)，前者有數(shù)據(jù)拉取的開銷，后者導(dǎo)致單實例性能瓶頸。

而且如果那個放queue的實例宕機了，會導(dǎo)致接下來其他實例就無法從那個實例拉取，如果你開啟了消息持久化，讓rabbitmq落地存儲消息的話，消息不一定會丟，得等這個實例恢復(fù)了，然后才可以繼續(xù)從這個queue拉取數(shù)據(jù)。

所以這個事兒就比較尷尬了，這就沒有什么所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集群中多個節(jié)點來服務(wù)某個queue的讀寫操作。

3）鏡像集群模式

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

這樣的話，好處在于，你任何一個機器宕機了，沒事兒，別的機器都可以用。壞處在于，第一，這個性能開銷也太大了吧，消息同步所有機器，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！第二，這么玩兒，就沒有擴展性可言了，如果某個queue負(fù)載很重，你加機器，新增的機器也包含了這個queue的所有數(shù)據(jù)，并沒有辦法線性擴展你的queue

那么怎么開啟這個鏡像集群模式呢？我這里簡單說一下，避免面試人家問你你不知道，其實很簡單rabbitmq有很好的管理控制臺，就是在后臺新增一個策略，這個策略是鏡像集群模式的策略，指定的時候可以要求數(shù)據(jù)同步到所有節(jié)點的，也可以要求就同步到指定數(shù)量的節(jié)點，然后你再次創(chuàng)建queue的時候，應(yīng)用這個策略，就會自動將數(shù)據(jù)同步到其他的節(jié)點上去了。

（2）kafka的高可用性

kafka一個最基本的架構(gòu)認(rèn)識：多個broker組成，每個broker是一個節(jié)點；你創(chuàng)建一個topic，這個topic可以劃分為多個partition，每個partition可以存在于不同的broker上，每個partition就放一部分?jǐn)?shù)據(jù)。

這就是天然的分布式消息隊列，就是說一個topic的數(shù)據(jù)，是分散放在多個機器上的，每個機器就放一部分?jǐn)?shù)據(jù)。

實際上rabbitmq之類的，并不是分布式消息隊列，他就是傳統(tǒng)的消息隊列，只不過提供了一些集群、HA的機制而已，因為無論怎么玩兒，rabbitmq一個queue的數(shù)據(jù)都是放在一個節(jié)點里的，鏡像集群下，也是每個節(jié)點都放這個queue的完整數(shù)據(jù)。

kafka 0.8以前，是沒有HA機制的，就是任何一個broker宕機了，那個broker上的partition就廢了，沒法寫也沒法讀，沒有什么高可用性可言。

kafka 0.8以后，提供了HA機制，就是replica副本機制。每個partition的數(shù)據(jù)都會同步到吉他機器上，形成自己的多個replica副本。然后所有replica會選舉一個leader出來，那么生產(chǎn)和消費都跟這個leader打交道，然后其他replica就是follower。寫的時候，leader會負(fù)責(zé)把數(shù)據(jù)同步到所有follower上去，讀的時候就直接讀leader上數(shù)據(jù)即可。只能讀寫leader？很簡單，要是你可以隨意讀寫每個follower，那么就要care數(shù)據(jù)一致性的問題，系統(tǒng)復(fù)雜度太高，很容易出問題。kafka會均勻的將一個partition的所有replica分布在不同的機器上，這樣才可以提高容錯性。

這么搞，就有所謂的高可用性了，因為如果某個broker宕機了，沒事兒，那個broker上面的partition在其他機器上都有副本的，如果這上面有某個partition的leader，那么此時會重新選舉一個新的leader出來，大家繼續(xù)讀寫那個新的leader即可。這就有所謂的高可用性了。

寫數(shù)據(jù)的時候，生產(chǎn)者就寫leader，然后leader將數(shù)據(jù)落地寫本地磁盤，接著其他follower自己主動從leader來pull數(shù)據(jù)。一旦所有follower同步好數(shù)據(jù)了，就會發(fā)送ack給leader，leader收到所有follower的ack之后，就會返回寫成功的消息給生產(chǎn)者。（當(dāng)然，這只是其中一種模式，還可以適當(dāng)調(diào)整這個行為）

消費的時候，只會從leader去讀，但是只有一個消息已經(jīng)被所有follower都同步成功返回ack的時候，這個消息才會被消費者讀到。

實際上這塊機制，講深了，是可以非常之深入的，但是我還是回到我們這個課程的主題和定位，聚焦面試，至少你聽到這里大致明白了kafka是如何保證高可用機制的了，對吧？不至于一無所知，現(xiàn)場還能給面試官畫畫圖。要遇上面試官確實是kafka高手，深挖了問，那你只能說不好意思，太深入的你沒研究過。

但是大家一定要明白，這個事情是要權(quán)衡的，你現(xiàn)在是要快速突擊常見面試題體系，而不是要深入學(xué)習(xí)kafka，要深入學(xué)習(xí)kafka，你是沒那么多時間的。你只能確保，你之前也許壓根兒不知道這塊，但是現(xiàn)在你知道了，面試被問到，你大概可以說一說。然后很多其他的候選人，也許還不如你，沒看過這個，被問到了壓根兒答不出來，相比之下，你還能說點出來，大概就是這個意思了。