??大家好，我是陳哈哈，北漂五年，相信大家和我一樣，都有一個大廠夢，作為一名資深Java選手，深知面試重要性，接下來我準備用100天時間，基于Java崗面試中的高頻面試題，以每日3題的形式，帶你過一遍熱門面試題及恰如其分的解答，

??一路走來，隨著問題加深，發現不會的也愈來愈多，但底氣著實足了不少，相信不少朋友和我一樣，榷訓月累才是最有效的學習方式！想起高三時一個同學的座右銘：只有沉下去，才能浮上來，共勉（juan），

坐標：日本 名古屋 小巷

作者：唐伯虎點香煙

??本欄目Java開發崗高頻面試題主要出自以下各技術堆疊：Java基礎知識、集合容器、并發編程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL資料庫、Redis快取、RabbitMQ訊息佇列、Linux操作技巧等，

??我們面試中常會被問到訊息佇列相關問題，但一般沒有過于深入原理的，因為進了公司后大多時候佇列都有專門的中間機組或人專門處理，基本輪不到咱們的~因此面試官主要還是想看你對佇列這塊兒的理解程度 以及 是否真會玩兒這個，就完了，因此不建議花費大量時間去深入研究原理，，有空多看看JVM和并發不香么，

??個人理解，面試主要考察MQ的點大概包括：你丫之前系統為啥要用訊息佇列？是咋用的？你會玩兒么，還是用別人玩兒剩下的？為啥選擇了這個MQ？常見的問題都知道咋整不？出問題你習慣背鍋還是甩鍋？，，，🙂🙂🙂

• 感覺認識到位的同學請點個贊~~

面試題1：說說你對訊息佇列的理解，訊息佇列為了解決什么問題？

??我們公司業務系統一開始體量較小，很多組件都是單機版就足夠，后來隨著用戶量逐漸擴大，我們程式也采用了微服務的設計思想，把很多服務進行了拆分，但后來在一些秒殺搶票活動或高頻業務中，服務依舊扛不住大量QPS，因此我們引入了訊息佇列來優化該類問題，

??訊息佇列應用的場景大致分為三類：解耦、異步、削峰，

解耦

??訊息佇列類似設計模式中的觀察者模式（Observer）或發布-訂閱模式（Pub-Sub），生產者生成和發送訊息到訊息佇列，消費者從訊息佇列中取走訊息進行處理，稱為消費，使用訊息佇列將“生產者”和“消費者”之間的操作關聯解耦，易于擴展，

??比如系統A為支付系統，一開始用戶支付完呼叫日志記錄系統B記錄就完了，后來內容越來越多，支付完成要呼叫加積分系統C、短信通知系統D、優惠券系統E等等…

??這個場景中，A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產生一條支付成功的資料，很多系統介面都需要 A 系統呼叫把支付成功的資料發送過去，A 系統程式員要時刻考慮這些問題：

• 其他系統如果掛了該咋辦？是不是直接程式拋例外了？
• 一天到晚加業務，每次都重新部署？領導是不是狗？

??那如果引入 MQ，A 系統產生一條資料，發送到 MQ 里面去，每個子系統加上對訊息佇列中支付成功訊息的訂閱，持續監聽就可以了，哪個系統需要資料自己去 MQ 里面消費，如果新系統需要資料，直接從 MQ 里消費即可；如果某個系統不需要這條資料了，就取消對 MQ 訊息的消費即可，

??這樣下來，A系統壓根兒不需要去考慮要給誰發送資料，不需要維護這個代碼，也不需要考慮人家是否呼叫成功、失敗超時等情況，我只負責把支付成功的資訊放到MQ里就行了，至于能否正常加積分、能否正常短信通知，管我鳥事！~~可見，通過一個 MQ，Pub/Sub 發布訂閱訊息這么一個模型，A 系統就跟其它系統徹底解耦了，

面試官：哦，那我聽出來了，你這是喜歡甩鍋啊！來，簡歷還你，

我：額，，不，我開玩笑的，當然不能這樣做，這里其實涉及到MQ在分布式事務中資料一致性的問題；聽我跟您解釋，

資料一致性

??這個其實是分布式服務本身就存在的一個問題，不僅僅是訊息佇列的問題，但是放在這里說是因為用了訊息佇列這個問題會更明顯，

??就像咱們上面說的，你支付成功的服務自己保證自己的邏輯成功處理了，你成功發了訊息，但是短信系統，積分系統等等這么多系統，他們成功還是失敗你就不管了？當然不行，這樣坑隊友的行為，狄大人都幫不了你~

??怎么辦？那就把所有的服務都放到一個事務里，所有都成功成功才能算這一次下單是成功的，要成功一起成功，要失敗一起失敗，

異步

??A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、400ms、200ms，最終請求總延時是 3 + 300 + 400 + 200 = 903ms，接近 1秒，用戶感覺搞個毛線？慢的一批，

??一般互聯網類的企業，對于用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內完成，對用戶幾乎是無感知的，如果1秒足以說明該系統不可用，垃圾系統，

??如果這里使用了訊息佇列，那么 A 系統連續發送 3 條訊息到 MQ 佇列中，假如耗時 5ms，A 系統從接受一個請求到回傳回應給用戶，總時長是 3 + 5 = 8ms，對于用戶而言，其實感覺上就是點個按鈕，8ms 以后就直接回傳了，體驗感很好

削峰

??比如我們系統有代售搶票業務，平時每天QPS也就50左右，A 系統風平浪靜，結果每次一到春運搶票，每秒并發請求數量突然會暴增到10000以上，但是系統是直接基于 MySQL 的，大量的請求直接打到 MySQL，比如一般MySQL能抗2000條請求，現在每秒10000 條 SQL，可能就直接把 MySQL 給打死了，導致系統崩潰，但是高峰期一過就又沒人了，QPS回到50，對整個系統幾乎沒有任何的壓力，

??如果這里使用 MQ，每秒 1w 個請求寫入 MQ，A 系統每秒鐘最多處理 2000 個請求，因為 MySQL 每秒鐘最多處理 2k 個，A 系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok了，這樣下來，哪怕是高峰期的時候，A 系統也不會掛掉，當然了，用戶的回應時間肯定會受影響，畢竟秒殺嘛，只要把前多少條請求處理好，其余的搶票失敗就行了，

??另外，MQ 每秒鐘 1w 個請求進來，只處理 2k 個請求出去，結果會導致在中午高峰期，可能有幾十萬甚至幾百萬的請求積壓在 MQ 中，

??這個短暫的高峰期積壓是 ok 的，因為高峰期過了之后，每秒鐘就 50 個請求進 MQ，但是A 系統依然會按照每秒 2k 個請求的速度在處理，所以說，只要高峰期一過，A 系統就會快速將積壓的訊息給消費掉，

追問1：訊息佇列有什么優缺點

• 系統可用性降低

??系統引入的外部依賴越多，越容易掛掉，本來你就是 A 系統呼叫 BCD 三個系統的介面就好了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整，MQ 一掛，整套系統崩潰的，你不就完了？如何保證訊息佇列的高可用？

• 系統復雜度提高

??硬生生加個 MQ 進來，你怎么保證訊息一定被消費？如何避免訊息重復投遞或重復消費？資料丟失怎么辦？怎么保證訊息傳遞的順序性？

• 一致性問題

??A 系統處理完了直接回傳成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這資料就不一致了，

課間休息，又來秀一下來自咱們群里同學的搬磚工地，坐標：香港，

作者：竹蜻蜓不會飛

面試題2：對于訊息中間機，你們是怎么做技術選型的？

??目前市面上比較主流的訊息佇列中間件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等，

??ActiveMQ和RabbitMQ這兩由于吞吐量的原因，只有業務體量一般的公司在用，RabbitMQ由于是erlang語言開發的，我們都不了解，因此擴展和維護成本都很高，查個問題都頭疼，

??Kafka和RocketMQ一直在各自擅長的領域發光發亮，兩者的吞吐量、可靠性、時效性等都很可觀，

我們通過圖表看看這幾個訊息中間機的對比：

??大家其實一下子就能看到差距了，就拿吞吐量來說，早期比較活躍的ActiveMQ 和RabbitMQ基本上不是后兩者的對手了，在現在這樣大資料的年代吞吐量是真的很重要，

課間休息，又來秀一下來自咱們群里同學的搬磚工地，坐標：廈門，

作者：曉海wiley

面試題3：如何確保訊息正確地發送至 RabbitMQ？如何確保訊息接收方消費了訊息？

發送方確認模式

??將信道設定成confirm模式（發送方確認模式），則所有在信道上發布的訊息都會被指派一個唯一的ID，

??一旦訊息被投遞到目的佇列后，或者訊息被寫入磁盤后（可持久化的訊息），信道會發送一個確認給生產者（包含訊息唯一ID），

??如果RabbitMQ發生內部錯誤從而導致訊息丟失，會發送一條Nack（not acknowledged，未確認）訊息，

??發送方確認模式是異步的，生產者應用程式在等待確認的同時，可以繼續發送訊息，當確認訊息到達生產者應用程式，生產者應用程式的回呼方法就會被觸發來處理確認訊息，

接收方確認機制

??消費者接收每一條訊息后都必須進行確認（訊息接收和訊息確認是兩個不同操作），只有消費者確認了訊息，RabbitMQ才能安全地把訊息從佇列中洗掉，

??這里并沒有用到超時機制，RabbitMQ僅通過Consumer的連接中斷來確認是否需要重新發送訊息，也就是說，只要連接不中斷，RabbitMQ給了Consumer足夠長的時間來處理訊息，保證資料的最終一致性；

追問1：如何保證MQ訊息的可靠傳輸？

??以我們常用的RabbitMQ為例，訊息不可靠的情況可能是訊息丟失，劫持等原因；

??丟失又分為：生產者丟失訊息、訊息佇列丟失訊息、消費者丟失訊息；

??生產者丟失訊息：從生產者弄丟資料這個角度來看，RabbitMQ提供confirm模式來確保生產者不丟訊息；

??confirm模式用的居多：一旦channel進入confirm模式，所有在該信道上發布的訊息都將會被指派一個唯一的ID（從1開始），一旦訊息被投遞到所有匹配的佇列之后；RabbitMQ就會發送一個ACK給生產者（包含訊息的唯一ID），這就使得生產者知道訊息已經正確到達目的佇列了；

??如果rabbitMQ沒能處理該訊息，則會發送一個Nack訊息給你，你可以進行重試操作，

??訊息佇列丟資料：訊息持久化，

??處理訊息佇列丟資料的情況，一般是開啟持久化磁盤的配置，

??持久化配置和confirm機制配合使用，在訊息持久化磁盤后，再給生產者發送一個Ack信號，

??這樣，如果訊息持久化磁盤之前，rabbitMQ陣亡了，那么生產者收不到Ack信號，生產者會自動重發，

面試官：那你說說如何避免訊息重復投遞或重復消費？訊息是基于什么傳輸的？

我：今天累了，不想說了，下次吧~

面試官：？？？

我：對了，簡歷給我來，

面試官：嘶~

我：怎么，玩不起了？

每日小結

??今天我們復習了面試中常考的訊息佇列相關的三個問題，你做到心中有數了么？對了，如果你的朋友也在準備面試，請將這個系列扔給他，如果他認真對待，肯定會感謝你的！！好了，今天就到這里，學廢了的同學，記得在評論區留言：打卡，，給同學們以激勵，