詳解ＭＱ消息隊列及四大主流ＭＱ的優(yōu)缺點

來自：光頭2強
鏈接：blog.csdn.net/qq_44240587/article/details/104630567

     

   正文   

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

end