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