來源：blog.csdn.net/qq_44240587/article/details/104630567
前言
近期有了想跳槽的打算，所以自己想鞏固一下自己的技術，想了解一些面試比較容易加分的項，近期準備深入研究一下Redis和MQ這兩樣，這總體上都是為了解決服務器并發的原因，剛翻到了一篇有關于MQ的，覺得寫得特別好，特此記錄一下，也算是為了加深自己的印象，
面試題切入
- 為什么要使用MQ
- 訊息佇列有什么優點和缺點
- kafka、ActiveMQ、RabbitMQ、RocketMQ有什么區別
面試官心理分析
首先，你們系統里面為什么要用MQ
不少去面試的人，都知道自己以前專案里面用過MQ、Redis，但是為什么用這個，卻不知道，這種人說白了就是為了用而用，又或者這個框架就是別人設計的，他自己都沒了解過里面的東西，自然也不知道為什么要用，如果面試的時候面試官問你這種問題你答不上來，可能已經被pass百分之三十了，面試官通常對這種人印象很不好，他怕你進了公司只會埋頭苦干，不懂得自己思考，
第二，你既然用了MQ，那你知不知道MQ有什么好處和壞處
如果沒考慮過這個問題一定要慎重回答，因為你沒考慮過這個，盲目的弄個MQ進系統，當下的問題可能是解決了，但萬一后面出了問題不是給公司留坑嗎，面試官就怕這樣的人，招進來干了一年，自己跳槽了，給系統挖一堆坑，留下無窮禍患，
第三，既然你用了MQ，比如其中一種MQ，那你當時做沒做過調研
別看別人用了MQ，咦，感覺挺好的，就自己瞎弄了一個，根本沒考慮過MQ的選型，比如kafka，每個MQ并沒有絕對的好處和壞處，現在業界流行的MQ各有各的好處，各有各的壞處，你要做的就是揚長避短，挑選最適合自己系統的MQ，
面試題剖析
①為什么要使用MQ
其實面試官問你這個問題就是想知道，你們公司有個什么樣的業務場景，這個業務場景有個什么技術挑戰，如果不用MQ可能會比較麻煩，包括現在用了MQ以后有哪些好處等等，先說一下MQ常見的使用場景吧，MQ的使用場景有很多，但是比較核心的就是：解耦、異步、削鋒，
系統解耦
首先舉例下面這個場景，現有ABCDE五個系統，最初的時候BCD三個系統都要呼叫A系統的介面獲取資料，一切都很正常，但是突然，D系統說：我不要了，你不用給我傳資料了，A系統無奈，只能修改代碼，將呼叫D系統的代碼洗掉，這時候還沒洗掉呢，E系統發送了請求，但是A系統這時候還沒處理完D系統的請求，A系統卒！！！徹底崩潰，看下圖↓↓↓↓↓↓↓↓↓↓↓
上述場景中，BCDE都需要用到A系統提供的資料，A系統跟其他四個系統嚴重耦合，需要時時刻刻考慮其他四個系統要是掛了怎么辦，需不需要重新發送資料給他們，這個時候的A系統內心是崩潰的，
但是如果使用了MQ之后 ，A系統的資料只需要放到MQ里面，其他的系統想請求獲取資料只需要去MQ里面消費即可，如果突然不想請求了，就取消對MQ的消費就行了，A系統根本不需要考慮給誰去回應這個資料，也不需要去維護代碼，也不用考慮其他系統是否呼叫成功，失敗超時等情況，詳細看下圖↓↓↓↓↓↓↓↓
另外，MQ 系列面試題和答案全部整理好了，微信搜索Java技術堆疊，在后臺發送：面試，可以在線閱讀，
面試技巧：你需要思考一下，在你自己的系統里面有沒有類似的情況，一個系統或者模塊，呼叫了多個系統或者模塊，它們互相之間的呼叫非常復雜，并且維護起來很麻煩，但其實這個呼叫是不需要直接同步呼叫介面的，如果用MQ給它異步化解耦也是可以的，你就需要思考在你的專案里，是不是可以用MQ給它進行系統的解耦，可以自己組織一下語言回答，
異步呼叫
場景二，還是ABCD四個系統，A系統收到一個請求，需要在自己本地寫庫，還需要往BCD三個系統寫庫，A系統自己寫本地庫需要3ms，往其他系統寫庫相對較慢，B系統200ms ，C系統350ms，D系統400ms，這樣算起來，整個功能從請求到回應的時間為3ms+200ms+350ms+400ms=953ms，接近一秒，對于用戶來說，點個按鈕要等這么長時間，基本是無法接受的，側面也反映出這家研發人員技術不咋地，詳情如下圖↓↓↓↓↓↓
一般的互聯網企業，對于用戶請求回應的時間要求在100ms-200ms之間，這樣，用戶的眼睛存在視覺暫停現象，用戶回應時間在此范圍內就可以了，所以上面的現象是不可取的，
如果用了MQ，用戶發送請求到A系統耗時3ms，A系統發送三條訊息到MQ，假如耗時5ms，用戶從發送請求到相應3ms+5ms=8ms，僅用了8ms，用戶的體驗非常好，
流量削峰
場景三，這次舉個實體吧，也是近期發生的，我們都知道 ，2020年爆發的這場新冠病毒，導致各大線上商城APP里面的口罩被搶購一空，在這種情況下，JD商城開啟了一場每晚八點的搶購3Q口罩的活動，每天下午三點進行預約，晚上八點搶購，從JD商城剛上線這個活動，我連續搶了近一個周，也算是見證了一個百萬并發量系統從出現問題到完善的一個程序，
最初第一天，我搶購的時候，一百多萬預約，到八點搶購估計也能有百萬的并發量，可是第一天，到八點我搶的時候，由于并發量太高，直接把JD服務器弄崩了，直接報了例外，可能JD在上線這個活動的時候也沒能夠想到會有那么高的并發，打了一個猝不及防，但是這只是在前一兩天出現報例外的情況，后面卻沒有再出現例外資訊，到后來再搶購只是回應的時間變得很慢，但是JD系統并沒有崩潰，這種情況下一般就是用了MQ（或者之前用了MQ，這次換了個吞吐量級別更高的MQ），也正是利用了MQ的三大好處之一——削峰，
JD系統每天0—19點，系統風平浪靜，結果一到八點搶購的時候，每秒并發達到百萬，假設JD資料庫沒秒能處理1.5w條并發請求（并非實際資料，主要為了舉例）,到八點搶購的時候，每秒并發百萬，這直接導致系統例外，但是八點一過，可能也就幾萬用戶在線操作，每秒的請求可能也就幾百條，對整個系統毫無壓力，
如果使用了MQ，每秒百萬個請求寫入MQ，因為JD系統每秒能處理1W+的請求，JD系統處理完然后再去MQ里面，再拉取1W+的請求處理，每次不要超過自己能處理的最大請求量就ok，這樣下來，等到八點高峰期的時候，系統也不會掛掉，但是近一個小時內，系統處理請求的速度是肯定趕不上用戶的并發請求的，所以都會積壓在MQ中，甚至可能積壓千萬條，但是高峰期過后，每秒只會有一千多的并發請求進入MQ，但是JD系統還是會以每秒1W+的速度處理請求，所以高峰期一過，JD系統會很快消化掉積壓在MQ的請求，在用戶那邊可能也就是等的時間長一點，但是絕對不會讓系統掛掉，
訊息佇列的優缺點
優點
上面已經說過了，系統解耦，異步呼叫，流量削峰，
缺點
①系統可用性降低： 系統引入的外部依賴越多，系統要面對的風險越高，拿場景一來說，本來ABCD四個系統配合的好好的，沒啥問題，但是你偏要弄個MQ進來插一腳，雖然好處挺多，但是萬一MQ掛掉了呢，那樣你系統不也就掛掉了，
②系統復雜程度提高： 非要加個MQ進來，如何保證沒有重復消費呢？如何處理訊息丟失的情況？怎么保證訊息傳遞的順序？問題太多，
③一致性的問題： A系統處理完再傳遞給MQ就直接回傳成功了，用戶以為你這個請求成功了，但是，如果在BCD的系統里，BC兩個系統寫庫成功，D系統寫庫失敗了怎么辦，這樣就導致資料不一致了，
所以，訊息佇列其實是一套非常復雜的架構，你在享受MQ帶來的好處的同時，也要做各種技術方案把MQ帶來的一系列的問題解決掉，等一切都做好之后，系統的復雜程度硬生生提高了一個等級，
四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）各自的優缺點
目前業界四大主流的MQ有kafka、ActiveMQ、RabbitMQ、RocketMQ，其他的MQ也有，不過比較冷門，就不用多說了，畫個表就明白了，↓↓↓↓↓↓↓↓
綜上所述，各種對比之后，我個人傾向于是：
一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；
后來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處于不可控的狀態，但是確實人是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是我提醒一下自己想好社區萬一突然黃掉的風險，對自己公司技術實力有絕對自信的，我推薦用RocketMQ，否則回去老老實實用RabbitMQ吧，人是活躍開源社區，絕對不會黃
所以中小型公司，技術實力較為一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
如果是大資料領域的實時計算、日志采集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范
ok，訊息佇列寫到這里就結束了，記得點個在看！！！！！
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/499715.html
標籤：Java
上一篇：day04_陣列