(1)尷尬的面試現場:第一幕面試
(2)尷尬的面試現場:第二幕數據庫
(3)別讓你學的技術成爲空中樓閣緩存
(4)千方百計的 「虐虐」 本身架構
「 這篇文章,給你們說一個一樣是不少人都很迷惑的問題,由於實在是太多同窗來問我相似的問題了,因此寫一篇文章給你們來講一下。併發
事情的原由是這樣子的:不少好學的同窗,都會本身平時研究不少的技術,好比常見的就是買書看書,參加在線培訓課程,購買一些知識付費的專欄,或者購買一些視頻課程。分佈式
可是這些好學的同窗在學了不少東西以後,出去面試都遇到了這樣的一個痛點問題:微服務
這些同窗簡歷上寫了不少高大上的技術,可是其實本身可能沒機會,或者還沒來得及在本身手頭負責的項目裏用過,並且本身負責的項目好像也沒很麼用戶量和併發量。高併發
因而面試官和候選人可能會展開以下一系列的問題:
學習
面試官設計
你說大家系統用了Redis,那你說說大家項目目前有多少用戶?
候選人
這個。。。。好像大概就幾百或者幾千?(或者有的人是小互聯網公司的,可能會說,大概有個百萬級的用戶量)
面試官
好吧,那你說一下大家系統天天日活是多少?
(解釋一下日活:若是一個公司的產品有100萬註冊用戶,但確定不是天天每一個人都會來用你的系統的啊!就好像註冊了一個APP,可能半年纔會用一次!這個日活,就是天天到底多少人來用)
候選人
啊?天天多少人來用?我這個還真的沒統計過啊。。大概可能有幾千或者幾萬我的?
面試官
行吧,那大家天天幾千或者幾萬我的來用,那天天的請求量有多大?
候選人
這個我還真的沒統計過啊,很差意思啊!
面試官
納尼?那你知道大家的系統高峯期QPS有多大碼?(QPS,Query Per Second,也就就是每秒有多少請求)
候選人
(內心感受快哭了,由於以爲這個面試要黃,爲啥什麼技術都沒問題,直接來這些啊)我真的不知道啊。。。
面試官
那你什麼都不知道,你說說大家系統爲何要用Redis緩存?還要搭建一個3臺機器組成的Redis Cluster,這緣由何在?
若是不用Redis,直接就用MySQL來抗能不能抗的住?
候選人
咱們當時用Redis。。。。咦?到底爲啥要用啊?我好像也忘了,就感受能夠把這個技術用一下,畢竟咱們花了時間來調研,因此以爲能夠用就用一下。
面試官
你這是典型的爲了用而用啊!那你簡歷上說,你熟悉高併發相關技術,包括Redis、RocketMQ,等等,那你到底作太高併發系統沒有啊?
候選人
好吧,我錯了,我確實不知道什麼是高併發,我就是學了這些技術而後就寫在簡歷上了。
面試官
(內心活動)咋回事,搞半天是沒相關經驗的,都是本身學了一下啊,好吧,那來壓一壓薪資,看來不能當資深碼農來對待了 ,就當作普通的來面一下好了
因而兩我的進入了一系列的技術問答,可是面試官內心有數,這個候選人最多就是給一個普通工程師的職位,由於其實他並無過技術在項目如何落地的一些經驗。
這個候選人痛定思痛,回來改了一下簡歷,說本身負責的系統,日活用戶幾十萬人,高峯期QPS能夠達到5000/s+。
而後心想,這回不會像上次同樣,把這個事兒給聊黃了吧。到了面試現場坐下來開始了跟面試官下面的對話:
面試官
大家用戶量多大?日活多少?天天請求量多大?高峯期QPS多高?
候選人
(成竹在胸,嘴角掛着迷之微笑。。。)註冊用戶100萬,天天日活幾十萬用戶,天天請求量有幾千萬,高峯期QPS最大有5000/s+。
面試官
奧,那大家線上的部署架構是怎麼作的,給我畫圖看看?
而後大家一共有哪些服務,每一個服務部署了多少臺機器?每臺機器是什麼配置?CPU和內存有多大?你的機器部署是怎麼抗住每秒5000請求的?
候選人
(心理活動)公司實際沒啥請求量,每一個服務就部署一臺機器,連配置本身都沒關注過,天知道每秒5000請求須要多少機器能夠抗住啊。。。
面試官
咦?你怎麼支支吾吾的,本身項目線上部署狀況都不清楚?
那若是大家從網關入口層進來的請求是5000/s的話,那你能畫圖說一下你負責的每一個服務的接口的QPS是多少?
而後大家的各個中間件,MySQL、Redis、ES、RocketMQ,他們各自的QPS都是多少?以及他們各自都部署了多少機器,每一個機器什麼配置?
候選人
這個。。。。我歷來沒考慮過,我還真的不知道啊!
面試官
那你簡歷說你係統能夠抗5000/s的併發請求,你根本不知道系統架構是怎麼抗住的啊!
候選人
…………
上面說的兩個面試場景,其實真的是很是真實的兩個場景,是不少不少同窗頻繁給我反饋的尷尬面試現場。
由於這些同窗學了不少東西,可是本身沒準備好技術在項目裏怎麼落地的,結果就慘了,出去面試就各類尷尬。
由於學了的技術沒落地過,那不至關於空中樓閣,你面試內心能不慌嗎?
因此這裏要給你們說的一點,就是本身平時會學不少的技術,可是必定要注意把這些技術儘可能嘗試落地用到本身手頭負責的項目裏去。
另外,光用是不行的,你平時得考慮好,假設你的項目的用戶量有百萬級,而後天天有幾千萬請求,高峯期每秒有好幾千請求。
那麼這個時候,你的每一個服務會有多高的QPS?每一個服務須要部署多少臺機器才能夠抗住?機器的配置是多高?
而後系統會對背後的MySQL、Redis、ES、RabbitMQ等數據庫以及中間件,產生多高的QPS?這些中間件須要部署多少臺機器,用多高配置的機器?
這些東西實際上是很是很是重要的,也是你在學習了N多技術以後,把技術真正轉化爲本身的東西須要作的不少消化性的事情。
因此,但願你們平時好好準備,多實踐,多動手。實際工做中多思考,多給本身設計各類場景,push本身去解決這些場景的技術難題。
你在平時工做中多 「虐虐」 本身,面試才能表現的更加成竹在胸、雲淡風輕。
一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上,
歡迎關注公衆號:石杉的架構筆記
週一至週五早八點半!精品技術文章準時送上!!!
十餘年BAT架構經驗傾囊相授