阿里三面，P9面試官是如何360°無死角考察候選人的？【石杉的架構筆記】

目錄

一、業務背景介紹

二、架構演進考察

三、對公司底層技術的原理考察

四、系統難點的考察

五、擅長技術的考察

六、總結

「 這篇文章，給你們分享一個同窗面試阿里某個部門時的經歷。

簡單說一下這個同窗面試的背景，自己技術底子還不錯，在幾個有必定知名度的中型互聯網公司工做過，而後以前打算嘗試一下阿里的職位，就去面試了。

第一輪和第二輪面試，所有都經過了，面試官評價也是基本技術素養還能夠，基礎也不錯，定級都是P6+的職級。

可是第三面是那個部門老大P9出來面試他，結果就掛在這裏了，因此把這個第三面的一些問題分享出來，給你們參考。

一、業務背景介紹

首先這個同窗上來先闡述了一下本身的一些項目經歷，當前他在公司裏主要是負責一個數據類的系統，業務邏輯並不複雜，可是有一點技術難度。

主要是天天都會有人調用他的接口，而後有數據會落入數據庫表中。

簡化一下來講，大概是這個背景，以下圖：

這個系統天天接口調用大概會落入數據庫中有20萬左右的數據量，那麼每月大概是600萬左右的數據量，每一年大概是近億級的數據量會落入數據庫中。

可是這是針對整個數據庫來講的，平攤到裏面核心的每一個表，大概每一個表每一年新增個千萬級別的數據量。

二、架構演進考察

系統就是這麼個狀況，接着面試官就開始發問了。。。

面試官

如今你的系統壓力其實不大，天天20萬新增數據量也不大，每一年哪怕單表新增千萬級數據其實也還算能夠接受。

第一個問題：若是假設你的系統承載的業務量翻了10倍，天天新增200萬數據，你的系統架構要如何演進？

若是你的系統承載的業務量翻了100倍，天天新增2000萬數據，你的系統架構要如何演進？

候選人

這個。。。咱們還沒這種需求，因此我暫時還沒想過這個問題。。。

面試官

心想：（這小夥子想面P6+ ？那是資深Java職位，起碼得有點架構演進的意識吧，怎麼一點意識都沒有）

面試官對面試者的印象有點扣分了。。

【旁白解讀】

實際上這類問題在BAT、美團、京東等大公司裏面試，都是常問的，爲何呢？

由於大公司裏的系統面對的就是業務常常翻倍的增加，系統壓力愈來愈大，因此每一年都要作幾回技術升級，一直要進行架構演進。

因此在互聯網公司裏，架構設計能力中很是關鍵的一環，就是針對業務增加，架構演進的能力是很是核心的。

你要有一個意識說若是你的業務量10倍增加，100倍增加，你的系統架構要如何演進？這幾乎是資深工程師必需要有的一個意識和能力。

其實你們能夠思考一下，若是10倍增加，單表每一年新增近億數據，還能用單庫單表的方式來承載嗎？

確定不行了，因此必然針對10倍增加的場景，須要引入分庫分表的技術，保證每一個庫每一個表分散必定的數據量，避免單表單庫數據量過大。

那麼你們再思考一下，若是100倍增加呢，每一年單表新增近10億數據，你分庫分表也不必定夠了。由於此時可能會有高併發訪問的問題，數據庫抗起來很吃力。

此時，你要不要考慮數據異構、冷熱分離等數據存儲的架構設計？

好比採用MySQL分庫分表 + 分佈式NoSQL數據庫 + Elasticsearch分佈式搜索 + Redis緩存的架構，來總體設計這個數據存儲架構。

你能夠先作冷熱分離的架構，好比最熱的數據放入分佈式NoSQL數據庫，專門承載當日數據的高併發寫入，以及高性能的讀寫。

而後每過一段時間，作數據歸檔，把NoSQL裏再也不頻繁使用的冷數據遷移到MySQL裏去歸檔。

最後就是應對海量數據的檢索，能夠把索引構建在Elasticsearch裏來應對，可是從NoSQL+MySQL的異構存儲來提取明細數據便可。

並且針對一些特別熱查詢的數據，能夠依託Redis作一個緩存。

其實那個P9面試官的面試評價裏，指望的也是候選人把這一套架構說出來。雖然P6+的職級不必定說有能力徹底hold住這個架構，可是起碼要有這個意識。

結果候選人徹底什麼都說不出來，那固然會讓人很失望了。

三、對公司底層技術的原理考察

這位同窗他們的系統有一部分的數據是放在特殊存儲服務裏的，用的是雲平臺上的存儲服務，並且存放在存儲服務裏的數據仍是很核心的數據。

因此面試官就開始問第二個問題了。

面試官

你能說說你對這種特殊存儲服務的理解嗎，他的原理是什麼？

大家用的雲平臺上的服務存儲他的架構是什麼樣的，大家的存儲是如何規劃的？

候選人

我。。。通常是調用API往裏面寫數據，詳細的還沒太多關注過

面試官

心想：（ 搞什麼鬼，核心數據放這種特殊的存儲服務裏，結果從沒關注過，起碼也得了解一下他的原理，把人家的文檔仔細看幾遍吧 ）

（ 並且對於本身的存儲是如何規劃的，容量是否充足，他是怎麼擴容的，怎麼什麼都不知道 ）

【旁白分析】

這是該同窗犯的第二個錯誤，不說資深工程師，就說做爲一個高級工程師，應該對本身負責的系統使用到的方方面面都有必定的瞭解。

好比你要是用了語音轉換API，或者是快遞公司的查詢API，那你起碼知道人家背後大體在幹什麼，或者問清楚人家API的QPS極限，以及大家的訪問量是多少。

大家用了特殊的存儲服務，起碼知道那種存儲服務的實現原理是什麼，存儲的容量規劃等等問題，這是一個高級工程師hold住本身工做的起碼工做素養。

四、系統難點的考察

面試氣氛尷尬，不過仍然繼續。。。

面試官

那你以爲大家這個系統最大的技術難點是什麼？

候選人

我想一想（思索10秒後）。。。好像沒什麼難的，主要就是一些接口，而後數據就落入數據庫了。。。

面試官

心想：（這傢伙難道在公司混日子？）

【旁白分析】

大公司面試必定會問你係統的難點是什麼，這表明你的項目經驗有多少含金量。

哪怕大家項目很low，你硬湊平時也得想辦法弄點新技術進去，沒難點也要湊點兒難點出來，不然去面試必然給人鄙視。

舉個例子，好比上面的這個系統，實際上他有一個步驟是要作數據遷移，也就是說把數據庫裏可能幾百萬數據量，一次性遷移到另一套存儲裏去

那麼這個數據遷移的步驟，其實涉及到千萬級的數據量遷移。

你如何保證數據遷移的效率？如何保證遷移後的數據準確性？在遷移的過程當中如何避免影響數據庫的性能？

像這些問題，其實你平時都應該考慮一下，做爲一個技術難點好好闡述一下吧。

五、擅長技術的考察

面試官

那你說說你認爲本身最擅長最有深度的技術吧

候選人

我好像平時本身用MQ技術比較多一些

面試官

那你說說Kafka、RabbitMQ、RocketMQ幾種MQ的對比，還有他們各自的原理。

它們分別如何實現分佈式消息隊列架構的，底層的機制都聊一下，對比一下特色以及優缺點。

候選人

心想：（。。。我要回家！）

【旁白分析】

大公司必定會考察你的技術深度，通常就是對你平時用的最多，或者最熟悉的技術深刻挖掘和考察，看你的技術深度有多深。

結果這個同窗本身說了MQ，可是對MQ的瞭解實際上很是的淺薄，深刻的東西都說不出來，那麼最後必定就是讓面試官很無語了。

六、總結

其實這個同窗技術底子仍是不錯的，包括一些技術的基礎，因此前兩輪面試都是過了的。可是第三輪面試考察的角度都是徹底不一樣的，一會兒暴露出來了他的能力缺陷。

對本身負責系統的架構演進徹底無心識，負責系統的難點從沒思考過，系統涉及的一些技術的細節不瞭解，沒有技術深度的積累，都致使他在三面表現很很差，最後就是直接掛掉。

因此但願你們經過這篇文章，吸收這位同窗的經驗教訓，平時多思考本身負責系統的技術難點，以及業務量成倍增加時架構如何演進，系統涉及到的各類技術的細節，以及積累相關技術的技術深度。

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上,

歡迎關注公衆號：石杉的架構筆記

週一至週五早八點半！精品技術文章準時送上！！！

十餘年BAT架構經驗傾囊相授