??? ?

? ?正文? ?

前言近期有了想跳槽的打算，所以自己想鞏固一下自己的技術(shù)，想了解一些面試比較容易加分的項(xiàng)，近期準(zhǔn)備深入研究一下Redis和MQ這兩樣，這總體上都是為了解決服務(wù)器并發(fā)的原因，剛翻到了一篇有關(guān)于MQ的，覺得寫得特別好，特此記錄一下，也算是為了加深自己的印象。面試題切入為什么要使用MQ消息隊(duì)列有什么優(yōu)點(diǎn)和缺點(diǎn)kafka、ActiveMQ、RabbitMQ、RocketMQ有什么區(qū)別面試官心理分析首先，你們系統(tǒng)里面為什么要用MQ不少去面試的人，都知道自己以前項(xiàng)目里面用過MQ、Redis，但是為什么用這個，卻不知道，這種人說白了就是為了用而用，又或者這個框架就是別人設(shè)計(jì)的，他自己都沒了解過里面的東西，自然也不知道為什么要用。如果面試的時候面試官問你這種問題你答不上來，可能已經(jīng)被pass百分之三十了，面試官通常對這種人印象很不好，他怕你進(jìn)了公司只會埋頭苦干，不懂得自己思考。第二，你既然用了MQ，那你知不知道MQ有什么好處和壞處如果沒考慮過這個問題一定要慎重回答，因?yàn)槟銢]考慮過這個，盲目的弄個MQ進(jìn)系統(tǒng)，當(dāng)下的問題可能是解決了，但萬一后面出了問題不是給公司留坑嗎，面試官就怕這樣的人，招進(jìn)來干了一年，自己跳槽了，給系統(tǒng)挖一堆坑，留下無窮禍患。第三，既然你用了MQ，比如其中一種MQ，那你當(dāng)時做沒做過調(diào)研別看別人用了MQ，咦，感覺挺好的，就自己瞎弄了一個，根本沒考慮過MQ的選型，比如kafka，每個MQ并沒有絕對的好處和壞處，現(xiàn)在業(yè)界流行的MQ各有各的好處，各有各的壞處，你要做的就是揚(yáng)長避短，挑選最適合自己系統(tǒng)的MQ。面試題剖析①為什么要使用MQ其實(shí)面試官問你這個問題就是想知道，你們公司有個什么樣的業(yè)務(wù)場景，這個業(yè)務(wù)場景有個什么技術(shù)挑戰(zhàn)，如果不用MQ可能會比較麻煩，包括現(xiàn)在用了MQ以后有哪些好處等等。先說一下MQ常見的使用場景吧，MQ的使用場景有很多，但是比較核心的就是：解耦、異步、削鋒。系統(tǒng)解耦首先舉例下面這個場景，現(xiàn)有ABCDE五個系統(tǒng)，最初的時候BCD三個系統(tǒng)都要調(diào)用A系統(tǒng)的接口獲取數(shù)據(jù)，一切都很正常，但是突然，D系統(tǒng)說：我不要了，你不用給我傳數(shù)據(jù)了，A系統(tǒng)無奈，只能修改代碼，將調(diào)用D系統(tǒng)的代碼刪除，這時候還沒刪除呢，E系統(tǒng)發(fā)送了請求，但是A系統(tǒng)這時候還沒處理完D系統(tǒng)的請求，A系統(tǒng)卒！！！徹底崩潰?？聪聢D↓↓↓↓↓↓↓↓↓↓↓上述場景中，BCDE都需要用到A系統(tǒng)提供的數(shù)據(jù)，A系統(tǒng)跟其他四個系統(tǒng)嚴(yán)重耦合，需要時時刻刻考慮其他四個系統(tǒng)要是掛了怎么辦，需不需要重新發(fā)送數(shù)據(jù)給他們，這個時候的A系統(tǒng)內(nèi)心是崩潰的。但是如果使用了MQ之后 ，A系統(tǒng)的數(shù)據(jù)只需要放到MQ里面，其他的系統(tǒng)想請求獲取數(shù)據(jù)只需要去MQ里面消費(fèi)即可，如果突然不想請求了，就取消對MQ的消費(fèi)就行了，A系統(tǒng)根本不需要考慮給誰去響應(yīng)這個數(shù)據(jù)，也不需要去維護(hù)代碼，也不用考慮其他系統(tǒng)是否調(diào)用成功，失敗超時等情況。詳細(xì)看下圖↓↓↓↓↓↓↓↓總結(jié)：通過MQ發(fā)布訂閱消息的模型，A系統(tǒng)就成功的跟其他系統(tǒng)解耦了。面試技巧：你需要思考一下，在你自己的系統(tǒng)里面有沒有類似的情況，一個系統(tǒng)或者模塊，調(diào)用了多個系統(tǒng)或者模塊，它們互相之間的調(diào)用非常復(fù)雜，并且維護(hù)起來很麻煩，但其實(shí)這個調(diào)用是不需要直接同步調(diào)用接口的，如果用MQ給它異步化解耦也是可以的，你就需要思考在你的項(xiàng)目里，是不是可以用MQ給它進(jìn)行系統(tǒng)的解耦，可以自己組織一下語言回答。異步調(diào)用場景二，還是ABCD四個系統(tǒng)，A系統(tǒng)收到一個請求，需要在自己本地寫庫，還需要往BCD三個系統(tǒng)寫庫，A系統(tǒng)自己寫本地庫需要3ms，往其他系統(tǒng)寫庫相對較慢，B系統(tǒng)200ms ，C系統(tǒng)350ms，D系統(tǒng)400ms，這樣算起來，整個功能從請求到響應(yīng)的時間為3ms+200ms+350ms+400ms=953ms，接近一秒，對于用戶來說，點(diǎn)個按鈕要等這么長時間，基本是無法接受的，側(cè)面也反映出這家研發(fā)人員技術(shù)不咋地。詳情如下圖↓↓↓↓↓↓一般的互聯(lián)網(wǎng)企業(yè)，對于用戶請求響應(yīng)的時間要求在100ms-200ms之間，這樣，用戶的眼睛存在視覺暫?，F(xiàn)象，用戶響應(yīng)時間在此范圍內(nèi)就可以了，所以上面的現(xiàn)象是不可取的。如果用了MQ，用戶發(fā)送請求到A系統(tǒng)耗時3ms，A系統(tǒng)發(fā)送三條消息到MQ，假如耗時5ms，用戶從發(fā)送請求到相應(yīng)3ms+5ms=8ms，僅用了8ms，用戶的體驗(yàn)非常好。搜索公眾號Linux中文社區(qū)后臺回復(fù)“命令行”，獲取一份驚喜禮包。流量削峰場景三，這次舉個實(shí)例吧，也是近期發(fā)生的，我們都知道 ，2020年爆發(fā)的這場新冠病毒，導(dǎo)致各大線上商城APP里面的口罩被搶購一空，在這種情況下，JD商城開啟了一場每晚八點(diǎn)的搶購3Q口罩的活動，每天下午三點(diǎn)進(jìn)行預(yù)約，晚上八點(diǎn)搶購，從JD商城剛上線這個活動，我連續(xù)搶了近一個周，也算是見證了一個百萬并發(fā)量系統(tǒng)從出現(xiàn)問題到完善的一個過程，最初第一天，我搶購的時候，一百多萬預(yù)約，到八點(diǎn)搶購估計(jì)也能有百萬的并發(fā)量，可是第一天，到八點(diǎn)我搶的時候，由于并發(fā)量太高，直接把JD服務(wù)器弄崩了，直接報(bào)了異常，可能JD在上線這個活動的時候也沒能夠想到會有那么高的并發(fā)，打了一個猝不及防，但是這只是在前一兩天出現(xiàn)報(bào)異常的情況，后面卻沒有再出現(xiàn)異常信息，到后來再搶購只是響應(yīng)的時間變得很慢，但是JD系統(tǒng)并沒有崩潰，這種情況下一般就是用了MQ（或者之前用了MQ，這次換了個吞吐量級別更高的MQ），也正是利用了MQ的三大好處之一——削峰。搜索公眾號Java架構(gòu)師技術(shù)后臺回復(fù)“Spring”，獲取一份驚喜禮包。JD系統(tǒng)每天0—19點(diǎn)，系統(tǒng)風(fēng)平浪靜，結(jié)果一到八點(diǎn)搶購的時候，每秒并發(fā)達(dá)到百萬，假設(shè)JD數(shù)據(jù)庫沒秒能處理1.5w條并發(fā)請求（并非實(shí)際數(shù)據(jù)，主要為了舉例）,到八點(diǎn)搶購的時候，每秒并發(fā)百萬，這直接導(dǎo)致系統(tǒng)異常，但是八點(diǎn)一過，可能也就幾萬用戶在線操作，每秒的請求可能也就幾百條，對整個系統(tǒng)毫無壓力。如果使用了MQ，每秒百萬個請求寫入MQ，因?yàn)镴D系統(tǒng)每秒能處理1W+的請求，JD系統(tǒng)處理完然后再去MQ里面，再拉取1W+的請求處理，每次不要超過自己能處理的最大請求量就ok，這樣下來，等到八點(diǎn)高峰期的時候，系統(tǒng)也不會掛掉，但是近一個小時內(nèi)，系統(tǒng)處理請求的速度是肯定趕不上用戶的并發(fā)請求的，所以都會積壓在MQ中，甚至可能積壓千萬條，但是高峰期過后，每秒只會有一千多的并發(fā)請求進(jìn)入MQ，但是JD系統(tǒng)還是會以每秒1W+的速度處理請求，所以高峰期一過，JD系統(tǒng)會很快消化掉積壓在MQ的請求，在用戶那邊可能也就是等的時間長一點(diǎn)，但是絕對不會讓系統(tǒng)掛掉。消息隊(duì)列的優(yōu)缺點(diǎn)優(yōu)點(diǎn)上面已經(jīng)說過了，系統(tǒng)解耦，異步調(diào)用，流量削峰。缺點(diǎn)①系統(tǒng)可用性降低：?系統(tǒng)引入的外部依賴越多，系統(tǒng)要面對的風(fēng)險越高，拿場景一來說，本來ABCD四個系統(tǒng)配合的好好的，沒啥問題，但是你偏要弄個MQ進(jìn)來插一腳，雖然好處挺多，但是萬一MQ掛掉了呢，那樣你系統(tǒng)不也就掛掉了。②系統(tǒng)復(fù)雜程度提高：?非要加個MQ進(jìn)來，如何保證沒有重復(fù)消費(fèi)呢？如何處理消息丟失的情況？怎么保證消息傳遞的順序？問題太多。③一致性的問題：?A系統(tǒng)處理完再傳遞給MQ就直接返回成功了，用戶以為你這個請求成功了，但是，如果在BCD的系統(tǒng)里，BC兩個系統(tǒng)寫庫成功，D系統(tǒng)寫庫失敗了怎么辦，這樣就導(dǎo)致數(shù)據(jù)不一致了。所以。消息隊(duì)列其實(shí)是一套非常復(fù)雜的架構(gòu)，你在享受MQ帶來的好處的同時，也要做各種技術(shù)方案把MQ帶來的一系列的問題解決掉，等一切都做好之后，系統(tǒng)的復(fù)雜程度硬生生提高了一個等級。四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）各自的優(yōu)缺點(diǎn)目前業(yè)界四大主流的MQ有kafka、ActiveMQ、RabbitMQ、RocketMQ。其他的MQ也有，不過比較冷門。就不用多說了，畫個表就明白了?！C上所述，各種對比之后，我個人傾向于是： 一般的業(yè)務(wù)系統(tǒng)要引入MQ，最早大家都用ActiveMQ，但是現(xiàn)在確實(shí)大家用的不多了，沒經(jīng)過大規(guī)模吞吐量場景的驗(yàn)證，社區(qū)也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；后來大家開始用RabbitMQ，但是確實(shí)erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處于不可控的狀態(tài)，但是確實(shí)人是開源的，比較穩(wěn)定的支持，活躍度也高；不過現(xiàn)在確實(shí)越來越多的公司，會去用RocketMQ，確實(shí)很不錯，但是我提醒一下自己想好社區(qū)萬一突然黃掉的風(fēng)險，對自己公司技術(shù)實(shí)力有絕對自信的，我推薦用RocketMQ，否則回去老老實(shí)實(shí)用RabbitMQ吧，人是活躍開源社區(qū)，絕對不會黃所以中小型公司，技術(shù)實(shí)力較為一般，技術(shù)挑戰(zhàn)不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎(chǔ)架構(gòu)研發(fā)實(shí)力較強(qiáng)，用RocketMQ是很好的選擇如果是大數(shù)據(jù)領(lǐng)域的實(shí)時計(jì)算、日志采集等場景，用Kafka是業(yè)內(nèi)標(biāo)準(zhǔn)的，絕對沒問題，社區(qū)活躍度很高，絕對不會黃，何況幾乎是全世界這個領(lǐng)域的事實(shí)性規(guī)范。ok，消息隊(duì)列寫到這里就結(jié)束了，記得點(diǎn)個在看！！！！！ IT技術(shù)分享社區(qū)個人博客網(wǎng)站：https://programmerblog.xyz文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠(yuǎn)程辦公：常用的遠(yuǎn)程協(xié)助軟件，你都知道嗎？51單片機(jī)程序下載、ISP及串口基礎(chǔ)知識硬件：斷路器、接觸器、繼電器基礎(chǔ)知識

總結(jié)

以上是生活随笔為你收集整理的详解ＭＱ消息队列及四大主流ＭＱ的优缺点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。