詳細說說對 訊息佇列的理解以及主流 的優缺點

2022-09-21 12:39:10 字數 3679 閱讀 5238

首先,你們系統裡面為什麼要用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給它非同步化解耦也是可以的,你就需要思考在你的專案裡,是不是可以用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,使用者的體驗非常好。

流量削峰

如果使用了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語言阻止了大量的j**a工程師去深入研究和掌控他,對公司而言,幾乎處於不可控的狀態,但是確實人是開源的,比較穩定的支援,活躍度也高;

不過現在確實越來越多的公司,會去用rocketmq,確實很不錯,但是我提醒一下自己想好社群萬一突然黃掉的風險,對自己公司技術實力有絕對自信的,我推薦用rocketmq,否則回去老老實實用rabbitmq吧,人是活躍開源社群,絕對不會黃

所以中小型公司,技術實力較為一般,技術挑戰不是特別高,用rabbitmq是不錯的選擇;大型公司,基礎架構研發實力較強,用rocketmq是很好的選擇

如果是大資料領域的實時計算、日誌採集等場景,用kafka是業內標準的,絕對沒問題,社群活躍度很高,絕對不會黃,何況幾乎是全世界這個領域的事實性規範

ok,訊息佇列寫到這裡就結束了,記得點個在看!!!!!

我對訊息佇列的理解

用訊息佇列進行程序間的通訊,需要記住兩個結構,4個函式 第乙個結構 struct ipc perm 此結構主要用於用於 許可權。第二個結構 struct msgid ds 四個函式 int msgget key t key,int flag 建立乙個訊息佇列結構 int msgctl int msg...

詳細說說shape model的使用

基於形狀匹配shape model是工程上用的最多的,掌握它就有了一張王牌。針對roi小區域建模板,應用場合 模板的形狀和大小一經製作完畢便不再改變,在查詢模板的過程中,只會改變模板的方向和位置等來匹配目標影象中的影象。定位物件內部的灰度值可以有變化,但物件輪廓一定要清晰平滑。匹配速度比灰度快 建立...

windows佇列訊息和非佇列訊息的詳細解釋

我們已經談到過,windows給視窗傳送訊息,這意味著windows呼叫視窗訊息處理程式。但是,windows程式也有乙個訊息迴圈,它呼叫getmessage從訊息佇列中取出訊息,並且呼叫dispatchmessage將訊息傳送給視窗訊息處理程式。那麼,windows程式是依次等待訊息 類似於普通程...