1. 程式人生 > >《吊打面試官》系列-訊息佇列基礎

《吊打面試官》系列-訊息佇列基礎

你知道的越多,你不知道的越多

點贊再看,養成習慣

GitHub上已經開源 https://github.com/JavaFamily 有一線大廠面試點腦圖、個人聯絡方式和人才交流群,歡迎Star和完善

前言

訊息佇列在網際網路技術儲存方面使用如此廣泛,幾乎所有的後端技術面試官都要在訊息佇列的使用和原理方面對小夥伴們進行360°的刁難。

作為一個在網際網路公司面一次拿一次Offer的麵霸,打敗了無數競爭對手,每次都只能看到無數落寞的身影失望的離開,略感愧疚(請允許我使用一下誇張的修辭手法)。

於是在一個寂寞難耐的夜晚,暖男我痛定思痛,決定開始寫《吊打面試官》系列,希望能幫助各位讀者以後面試勢如破竹,對面試官進行360°的反擊,吊打問你的面試官,讓一同面試的同僚瞠目結舌,瘋狂收割大廠Offer!

絮叨

這期本來是準備大家投票出來的哈,然後在Java基礎和訊息佇列選一個寫的,但是我一想,Java基礎光是集合每種集合我都可以寫好幾篇了,基礎都得寫幾個月了,那是不是可以先把短的這個訊息佇列寫了?

我腦子靈光一閃,拍了下桌子,那就這麼決定了吧!

所以就有這期了哈哈。

重要!在開始之前我想問一下,大家是喜歡我直接懟知識點用自己的語言組織的方式講,還是這樣面試場景的方式講?

因為我發現一個很嚴肅的問題,我的開場和結尾要是幾百篇都差不多,最後你們會不會厭倦呀?

總之這個建議對我很有用,或者你有什麼寫作的建議都可以去GitHub https://github.com/JavaFamily 上面有我的聯絡方式,可以加我微信悄悄跟我說。

面試開始

一個風度翩翩,穿著格子襯衣的中年男子,拿著一個滿是劃痕的mac向你走來,看著錚亮的頭,心想著肯定是尼瑪頂級架構師吧!但是我們看過暖男敖丙的系列,腹有詩書氣自華,虛都不虛。

小夥子之前問了你這麼多Redis的知識,你不僅對答如流,你還能把各自場景的解決方案,優缺點說得這麼流暢,說你是不是看過敖丙寫的《吊打面試官》系列呀?

驚!!!老師你怎麼知道的,我看了他的系列根本停不下來啊。

呵呵,Redis沒難住你,但是我問個新的技術棧我還怕難不住你?我問問你你專案中用過訊息佇列麼?你為啥用訊息佇列?

噗此,這也叫問題?別人用了我能不用麼?別人用了我就用了唄,我就是為了用而用。

你心裡嘀咕就好了,千萬別說出來哈,說出來了沒拿到Offer別到時候就在那說,敖丙那個渣男教我說的!

面試官你好:我們公司本身的業務體量很小,所以直接單機一把梭啥都能搞定了,但是後面業務體量不斷擴大,採用微服務的設計思想,分散式的部署方式,所以拆分了很多的服務,隨著體量的增加以及業務場景越來越複雜了,很多場景單機的技術棧和中介軟體以及不夠用了,而且對系統的友好性也下降了,最後做了很多技術選型的工作,我們決定引入訊息佇列中介軟體。

哦?你說到業務場景越來越複雜,你那說一下你都在什麼場景用到了訊息佇列?

嗯,我從三個方面去說一下我使用的場景吧。

Tip:這三個場景也是訊息佇列的經典場景,大家基本上要爛熟於心那種,就是一說到訊息佇列你腦子就要想到非同步、削峰、解耦,條件反射那種。

非同步:

我們之前的場景裡面有很多步驟都是在一個流程裡面需要做完的,就比如說我的下單系統吧,本來我們業務簡單,下單了付了錢就好了,流程就走完了。

但是後面來了個產品經理,搞了個優惠券系統,OK問題不大,流程裡面多100ms去扣減優惠券。

後來產品經理靈光一閃說我們可以搞個積分系統啊,也行吧,流程裡面多了200ms去增減積分。

再後來後來隔壁的產品老王說:下單成功後我們要給使用者發簡訊,也將就吧,100ms去發個簡訊。

再後來。。。(敖丙你有完沒完!!!)

反正就流程有點像這樣 ↓

你們可以看到這才加了三個,我可以斬釘截鐵的告訴你真正的下單流程涉及的系統絕對在10個以上(主流電商),越大的越多。

這個鏈路這樣下去,時間長得一批,使用者發現我買個東西你特麼要花幾十秒,垃圾電商我不在你這裡買了,不過要是都像並夕夕這麼便宜,真香!

但是我們公司沒有夕夕的那個經濟實力啊,那隻能優化系統了。

Tip:我之前在的電商老東家要求所有介面的Rt(ResponseTime響應時間)在200ms內,超出的全部優化,我現在所負責的系統QPS也是9W+就是抖動一下網路叢集都可能炸鍋那種,RT基本上都要求在50ms以內。

大家感受一下這個QPS。

嗯不錯,鏈路長了就慢了,那你怎麼解決的?

那鏈路長了就慢了,但是我們發現上面的流程其實可以同時做的呀,你支付成功後,我去校驗優惠券的同時我可以去增減積分啊,還可以同時發個簡訊啊。

那正常的流程我們是沒辦法實現的呀,怎麼辦,非同步。

你對比一下是不是發現,這樣子最多隻用100毫秒使用者知道下單成功了,至於簡訊你遲幾秒發給他他根本不在意是吧。

小夥子我打斷你一下,你說了非同步,那我用執行緒,執行緒池去做不是一樣的麼?

誒呀,面試官你不要急嘛,我後面還會說到的,騷等。

解耦:

既然面試官這麼問了,我就說一下為啥我們不能用執行緒去做,因為用執行緒去做,你是不是要寫程式碼?

你一個訂單流程,你扣積分,扣優惠券,發簡訊,扣庫存。。。等等這麼多業務要呼叫這麼多的介面,每次加一個你要呼叫一個介面然後還要重新發布系統,寫一次兩次還好,寫多了你就說:老子不幹了!

而且真的全部都寫在一起的話,不單單是耦合這一個問題,你出問題排查也麻煩,流程裡面隨便一個地方出問題搞不好會影響到其他的點,小夥伴說我每個流程都try catch不就行了,相信我別這麼做,這樣的程式碼就像個定時炸彈