MQ相關面試題

如果你的簡歷中有寫到mq，那麼面試官一般會問到如下幾個問題，至少我在面試中經常常被問到，所以今天總結一下，有不對的地方還望多多包涵：

首先第乙個問題，為什麼要用mq？

如果這個問題你都沒考慮過，那麼說明你只是乙個單純會用mq技術的乙個coder，而不是乙個會獨立思考的程式設計師，如果被面試官問到這個問題，你都沒有回答上來，那麼你的第一印象肯定會很差。

一、為什麼要用mq？

（1）解耦：如果多個模組或者系統中，互相呼叫很複雜，維護起來比較麻煩，但是這個呼叫又不是同步呼叫，就可以運用mq到這個業務中。

（2）非同步：這個很好理解，比如使用者的操作日誌的維護，可以不用同步處理，節約響應時間。

（3）削峰：在高峰期的時候，系統每秒的請求量達到 5000，那麼呼叫 mysql 的請求也是 5000，一般情況下 mysql 的請求大概在 2000 左右，那麼在高峰期的時候，資料庫就被打垮了，那系統就不可用了。此時引入mq，在系統 a 前面加個 mq，使用者請求先到 mq，系統 a 從 mq 中每秒消費 2000 條資料，這樣就把本來 5000 的請求變為 mysql 可以接受的請求數量了，可以保證系統不掛掉，可以繼續提供服務。mq 裡的資料可以慢慢的把它消費掉。

二、使用了mq會有什麼問題？

這個問題記住乙個降低乙個增加即可。

（1）降低了系統可用性（2）增加了系統的複雜性

三、怎樣選型mq？

如果你被問及這個問題，面試官主要是想看你選型的時候是否會比較架構的區別，是否滿足業務需求。

特性

activemq

rabbitmq

rocketmq

kafka

單機吞吐量

萬級萬級

十萬級十萬級

topic 數量對吞吐量的影響--

topic 可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降

topic 從幾十個到幾百個的時候，吞吐量會大幅度下降

時效性毫秒級

微妙級毫秒級

毫秒級可用性高高

非常高，分布式架構

訊息可靠性

有較低的概率丟失資料

-經過引數優化配置，可以做到 0 丟失

經過引數優化配置，訊息可以做到 0 丟失

功能支援

完善併發能力很強，效能極其好，延時很低

mq 功能較為完善，還是分布式的，擴充套件性好

功能較為簡單，主要支援簡單的 mq 功能，在大資料領域的實時計算以及日誌採集被大規模使用，是事實上的標準

優劣勢總結

非常成熟，功能強大；偶爾會有較低概率丟失訊息；社群不活躍了

效能極其好，延時很低；功能完善；提供管理介面；社群比較活躍；吞吐量較低；使用 erlang 開發原始碼閱讀不方便；

介面簡單易用；吞吐量高；分布式擴充套件方便；社群還算活躍；經過雙 11 的考驗

mq 功能比較少；吞吐量高；分布式架構；可能存在訊息重複消費問題；主要適用大資料實時計算以及日誌收集；

個人建議：

中小型公司，技術一般，可以考慮用 rabbitmq；

大型公司，基礎架構研發實力較強，用 rocketmq 是很好的選擇

實時計算、日誌採集：使用 kafka；

四、怎樣保證mq的高可用？

rabbitmq是比較有代表性的，因為是基於主從做高可用性的。以他為例，自行查閱以下模式。

rabbitmq有三種模式：單機模式、普通集群模式、映象集群模式。

五、如何保證不被重複消費？

不通的消費佇列都會有乙個消費通知的機制，如：

rabbitmq提供了乙個ack確認訊息機制，

rocketmq返回乙個consume_success成功標誌

(1)比如，你拿到這個訊息做資料庫的insert操作。那就容易了，給這個訊息做乙個唯一主鍵，那麼就算出現重複消費的情況，就會導致主鍵衝突，避免資料庫出現髒資料。

(2)再比如，你拿到這個訊息做redis的set的操作，那就容易了，不用解決，因為你無論set幾次結果都是一樣的，set操作本來就算冪等操作。

(3)如果上面兩種情況還不行，上大招。準備乙個第三方介質,來做消費記錄。以redis為例，給訊息分配乙個全域性id，只要消費過該訊息，將以k-v形式寫入redis。那消費者開始消費前，先去redis中查詢有沒消費記錄即可。

六、如何保證消費的可靠傳輸性？

每個mq都要從生產者丟失資料、消費佇列丟失資料、消費丟失資料三個層面回答

(1) 生產者丟失資料

以rabbitmq為例，rabbitmq提供了transaction和confirm模式來確保生產者不丟失資料，事務機制，傳送訊息前，開啟事務（channel.txselect()）,傳送訊息後出現異常，事務回滾（channel.txrollback()）,傳送成功提交事務（channel.txcommit()）。

上面這種方式吞吐量會下降，因此生產上應該使用confirm模式居多。

一旦channel進入confirm模式，所有在該通道發布上的訊息都會被指派乙個唯一的id（從1開始），訊息進來如佇列後，rabbitmq會立即傳送乙個ack給生產者，其中包含了訊息的唯一id，這就使得生產者知道訊息已經到達了訊息佇列裡。如果訊息佇列沒能處理該訊息，則會傳送乙個nack給生產者進行重試操作。

channel.addconfirmlistener(new
confirmlistener() 
@override
public
void handleack(long deliverytag, boolean multiple) throws
ioexception 
});

(2) 訊息佇列丟失資料

訊息佇列丟失的情況一般是開啟持久化硬碟配置，這個持久化配置可以和confirm機制配合使用，可以在持久化硬碟之後，傳送乙個ack給生產者，如果生產者收不到ack資訊，會重發資訊。

如何持久化硬碟：

①將queue的持久化標識durable設定為true，

②傳送訊息的時候將deliverymode=2

這樣設定就算rabbitmq掛了，重啟後也能恢復資料

(3) 消費者丟失資料

解決方案：採用手動確認訊息。

七、如何保證訊息的時序性？

先進先出佇列，比如linkedblockingqueue。

MQ相關面試題

MQ常見面試題

面試題相關

前端面試題 css相關面試題

MQ相關面試題

MQ常見面試題

面試題相關

前端面試題 css相關面試題

相關推薦