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

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

貴州 苗寨 夜景

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

面試題1：我們知道MQ有可能發生重復消費，啥導致的？

??在一般網路環境下，都存在一定的網路延遲、網路抖動，網路問題導致訊息重復發送的情況是難以避免的，畢竟網路環境無法預知，因此MQ默認允許訊息重復發送，是的，只要通過網路交換資料，就無法避免這個問題，秉承著打不過就加入的原則，解決這個問題的辦法就是繞過這個問題，

那么問題就變成了：如果消費端收到兩條一樣的訊息，應該怎樣處理？

??RabbitMQ、RocketMQ、Kafka，都有可能會出現訊息重復消費的問題，因為這問題通常不是 MQ 自己保證的，而是消費方自己來保證的，

??比如說Kafka， 他實際上有個 offset 的概念（偏移量），就是每個訊息寫進去，都有一個 offset，代表訊息的序號，然后 consumer 消費了資料之后，每隔一段時間（定時定期），會把自己消費過的訊息的 offset 提交一下，代表我已經消費過了，就算消費者重啟，Kafka也會讓消費者繼上次消費到的offset繼續消費，

場景示例：

??kafka 中有一條資料：A、B，kafka給這條資料分一個 offset（偏移量），offset為： 1001、1002，消費者從 kafka 去消費的時候，也是按照這個順序去消費，當消費者消費到 offset=1002 的這條資料（此時offset=1001還沒消費完），剛提交 offset=1002 到 zookeeper，消費者行程就被重啟了，此時消費過的資料 A 的 offset 還沒有提交，kafka 也就不知道消費者已經消費了1001這條資料，那么重啟之后，消費者會找 Kafka 把上次消費到的那個地方后面的資料繼續傳遞過來，資料 A 再次被消費，

??如果消費者是拿到一條資料就往資料庫里寫一條，就會導致把資料 A 在資料庫里插入了 2 次，導致資料不一致，重復消費其實并不可怕，可怕的是你沒考慮到重復消費時，怎么保證冪等性，

追問1：如何保證訊息不被重復消費？如何實作冪等性？

冪等性，比如一個資料或者一個請求，給后臺重復發多次，針對這類情況，你得確保對應的資料結果是不會改變的，不能因為發了多個相同請求導致資料出錯，

怎么保證訊息佇列消費的冪等性？

• 比如你拿個資料要寫庫，你先根據主鍵查一下，如果這資料都有了，你就別插入了，update就行，對了，ES的插入介面是不是就采用了插入并更新的策略？發現相同的資料就直接更新他，
• 如果是寫 Redis，那沒問題，反正每次都是set，天然冪等性，
• 比如你不是上面兩個場景，那做的稍微復雜一點，你需要讓生產者發送每條資料的時候，里面加一個全域唯一的 id，類似訂單 id 之類的東西，然后你這里消費到了之后，先根據這個 id 去 Redis 里查一下，之前消費過嗎？如果沒有消費過，你就處理，然后這個 id 寫 進Redis，如果消費過了，那你就別處理了，保證別重復處理相同的訊息即可，
• 比如基于資料庫的唯一鍵來保證重復資料不會重復插入多條，因為有唯一鍵約束了，重復資料插入只會報錯，不會導致資料庫中出現臟資料，（類似于第一條，可以通過修改SQL，轉成插入或更新的策略）

MySQL中的插入或替換、插入或更新、插入或忽略策略，詳情可參考《MySQL中特別實用的幾種SQL陳述句送給大家》

課間休息，看看 廣州 城中村一角，

面試題2：RabbitMQ如何保證訊息的順序性

??訊息佇列中的若干訊息如果是對同一個資料進行操作，這些操作又具有先后關系，必須按順序執行，否則可能會造成資料錯誤，

??比如有三個請求，是對資料庫中的同一條資料進行了插入->更新->洗掉操作，執行順序必須保證，如果變成洗掉->更新->插入就很可笑了，造成最終資料不一致，

順序錯亂的場景：

??一個queue，有多個consumer去消費，這樣就會造成順序的錯誤，consumer從MQ里面讀取資料是有序的，但是每個consumer的執行時間是不固定的，無法保證先讀到訊息的consumer一定先執行完操作，這樣就會出現訊息并沒有按照順序執行，造成資料順序錯誤，

rabbitmq如何保證訊息的消費順序

??將原來的一個queue拆分成多個queue，每個queue都有一個自己的consumer，該種方案的核心是生產者在投遞訊息的時候根據業務資料關鍵值（例如訂單ID哈希值對訂單佇列數取模）來將需要保證先后順序的同一類資料（同一個訂單的資料） 發送到同一個queue當中，讓同一個consumer來按順序處理，

圖片取自中華石杉架構課件

??一個queue就一個consumer，在consumer中維護多個記憶體佇列，根據業務資料關鍵值（例如訂單ID哈希值對記憶體佇列數取模）將訊息加入到不同的記憶體佇列中，然后多個真正負責處理訊息的執行緒去各自對應的記憶體佇列當中獲取訊息進行消費，

圖片取自中華石杉架構課件

RabbitMQ保證訊息順序性總結：

??核心思路就是根據業務資料關鍵值劃分成多個訊息集合，而且每個訊息集合中的訊息資料都是有序的，每個訊息集合有自己獨立的一個consumer，多個訊息集合的存在保證了訊息消費的效率，每個有序的訊息集合對應單個的consumer也保證了訊息消費時的有序性，也就是保證了生產者 - MQServer - 消費者是一對一對一的關系，

休息一下

面試題3：訊息佇列滿了以后該怎么處理？比如現在大量訊息在MQ里長時間積壓，你會如何解決？

??這種就是問的實際業務場景中的問題，這種情況原因一般是：消費者consumer出了bug或性能問題，消費量遠低于訊息增量，導致訊息積壓越來越多，幾百萬至上千萬，就算consumer及時恢復，也要吃幾個小時才能吃完，同時，已經出現部分積壓的訊息過期失效，丟失了資料，

這時候首先想到的是橫向擴consumer，先把這些訊息盡快吃掉再說，，具體如下：

1. 先修復consumer的問題，確保其恢復消費速度，然后將現有cnosumer都停掉；
2. kafka的話，比如新建一個topic，partition是原來的10倍，臨時建立好原先10倍或者20倍的queue數量；
3. 寫一個臨時的分發資料的consumer程式，這個程式部署上去消費積壓的資料，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的10倍數量的queue里去；
4. 接著臨時征用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的資料；
5. 這種做法相當于是臨時將queue資源和consumer資源擴大10倍，以正常的10倍速度來消費資料；
6. 等快速消費完積壓資料之后，恢復成原來部署，

追問1：MQ訊息過期失效怎么辦？

??像上面說到的，如果大量積壓中的訊息過期了，就會被刪掉，資料就丟失了，這種其實沒有啥好辦法，只能等解決積壓問題后再處理了，

??比如夜深人靜，大家都睡覺了，這時積壓的訊息也吃完了，你揉了揉眼，沖了一杯免費咖啡，找到寫好的程式，把過期的資料找回來并重新放到MQ中，讓他重新消費一遍就行了，

追問3：如果mq經常寫滿你會怎么辦？

??這樣如果是消費者這邊的硬傷，就只能擴容來搞了，多加一些服務器部署消費者程式，當然，如果可以通過優化程式解決，肯定要選擇后者，無論從技識訓是業務角度來優化，否則經常寫滿就意味著經常丟資料，只能人工寫程式去補資料，作業量更大，加班更嚴重，我可不愿意加班，

面試官：哦？我們這邊是狼性文化，不考慮不愿意加班的~

我：那你把…

面試官：嘶~

我：? ? ?

每日小結

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