如何才能進阿里巴巴工作

這篇文章，給大家分享一個同學面試阿里某個部門時的經(jīng)歷。簡單說一下這個同學面試的背景，本身技術底子還不錯，在幾個有一定知名度的中型互聯(lián)網(wǎng)公司工作過，然后之前打算嘗試一下阿里的職位，就去面試了。第一輪和第二輪面試，全部都通過了，面試官評價也是基本技術素養(yǎng)還可以，基礎也不錯，定級都是P6+的職級。但是第三面是那個部門老大P9出來面試他，結果就掛在這里了，所以把這個第三面的一些問題分享出來，給大家參考。業(yè)務背景介紹這個同學上來先闡述了一下自己的一些項目經(jīng)歷，當前他在公司里主要是負責一個數(shù)據(jù)類的系統(tǒng)，業(yè)務邏輯并不復雜，但是有一點技術難度。主要是每天都會有人調用他的接口，然后有數(shù)據(jù)會落入數(shù)據(jù)庫表中。簡化一下來說，大概是這個背景，如下圖：這個系統(tǒng)每天接口調用大概會落入數(shù)據(jù)庫中有20萬左右的數(shù)據(jù)量，那么每個月大概是600萬左右的數(shù)據(jù)量，每年大概是近億級的數(shù)據(jù)量會落入數(shù)據(jù)庫中。但是這是針對整個數(shù)據(jù)庫來說的，平攤到里面核心的每個表，大概每個表每年新增個千萬級別的數(shù)據(jù)量。架構演進考察面試官：現(xiàn)在系統(tǒng)壓力其實不大，每天20萬新增數(shù)據(jù)量也不大，每年哪怕單表新增千萬級數(shù)據(jù)其實也還算可以接受。第一個問題：如果假設你的系統(tǒng)承載的業(yè)務量翻了10倍，每天新增200萬數(shù)據(jù)，你的系統(tǒng)架構要如何演進？如果系統(tǒng)承載的業(yè)務量翻了100倍，每天新增2000萬數(shù)據(jù)，你的系統(tǒng)架構要如何演進？候選人：我們還沒這種需求，所以我暫時還沒想過這個問題。建議：實際上這類問題在BAT、美團、京東等大公司里面試，都是常問的，為什么呢？因為大公司里的系統(tǒng)面對的就是業(yè)務經(jīng)常翻倍的增長，系統(tǒng)壓力越來越大，所以每年都要做幾次技術升級，一直要進行架構演進。所以在互聯(lián)網(wǎng)公司里，架構設計能力中非常關鍵的一環(huán)，就是針對業(yè)務增長，架構演進的能力是非常核心的。你要有一個意識說如果你的業(yè)務量10倍增長，100倍增長，你的系統(tǒng)架構要如何演進？這幾乎是資深工程師必須要有的一個意識和能力。其實大家可以思考一下，如果10倍增長，單表每年新增近億數(shù)據(jù)，還能用單庫單表的方式來承載嗎？肯定不行了，所以必然針對10倍增長的場景，需要引入分庫分表的技術，保證每個庫每個表分散一定的數(shù)據(jù)量，避免單表單庫數(shù)據(jù)量過大。那么大家再思考一下，如果100倍增長呢，每年單表新增近10億數(shù)據(jù)，你分庫分表也不一定夠了。因為此時可能會有高并發(fā)訪問的問題，數(shù)據(jù)庫抗起來很吃力。此時，你要不要考慮數(shù)據(jù)異構、冷熱分離等數(shù)據(jù)存儲的架構設計？比如采用MySQL分庫分表+分布式NoSQL數(shù)據(jù)庫+Elasticsearch分布式搜索+Redis緩存的架構，來整體設計這個數(shù)據(jù)存儲架構。先做冷熱分離的架構，比如最熱的數(shù)據(jù)放入分布式NoSQL數(shù)據(jù)庫，專門承載當日數(shù)據(jù)的高并發(fā)寫入，以及高性能的讀寫。然后每過一段時間，做數(shù)據(jù)歸檔，把NoSQL里不再頻繁使用的冷數(shù)據(jù)遷移到MySQL里去歸檔。最后就是應對海量數(shù)據(jù)的檢索，可以把索引構建在Elasticsearch里來應對，但是從NoSQL+MySQL的異構存儲來提取明細數(shù)據(jù)即可。而且針對一些特別熱查詢的數(shù)據(jù)，可以依托Redis做一個緩存。其實那個P9面試官的面試評價里，期望的也是候選人把這一套架構說出來。雖然P6+的職級不一定說有能力完全hold住這個架構，但是起碼要有這個意識。結果候選人完全什么都說不出來，那當然會讓人很失望了。對公司底層技術的原理考察這位同學他們的系統(tǒng)有一部分的數(shù)據(jù)是放在特殊存儲服務里的，用的是云平臺上的存儲服務，而且存放在存儲服務里的數(shù)據(jù)還是很核心的數(shù)據(jù)。所以面試官就開始問第二個問題了。面試官：你能說說你對這種特殊存儲服務的理解嗎，原理是什么？你們用的云平臺上的服務存儲他的架構是什么樣的，你們的存儲是如何規(guī)劃的？候選人：我一般是調用API往里面寫數(shù)據(jù)，詳細的還沒太多關注過。建議：這是該同學犯的第二個錯誤，不說資深工程師，就說作為一個高級工程師，應該對自己負責的系統(tǒng)使用到的方方面面都有一定的了解。比如你要是用了語音轉換API，或者是快遞公司的查詢API，那你起碼知道人家背后大致在干什么，或者問清楚人家API的QPS極限，以及訪問量是多少。你們用了特殊的存儲服務，起碼知道那種存儲服務的實現(xiàn)原理是什么，存儲的容量規(guī)劃等等問題，這是一個高級工程師hold住自己工作的起碼工作素養(yǎng)。系統(tǒng)難點的考察面試氣氛尷尬，不過仍然繼續(xù)。面試官：那你覺得這個系統(tǒng)最大的技術難點是什么？候選人：我想想（思索10秒后），好像沒什么難的，主要就是一些接口，然后數(shù)據(jù)就落入數(shù)據(jù)庫了。建議：大公司面試一定會問你系統(tǒng)的難點是什么，這代表你的項目經(jīng)驗有多少含金量。哪怕你們項目很Low，平時也得想辦法弄點新技術進去，沒難點也要湊點兒難點出來，否則去面試必然給人鄙視。舉個例子，比如上面的這個系統(tǒng)，實際上他有一個步驟是要做數(shù)據(jù)遷移，也就是說把數(shù)據(jù)庫里可能幾百萬數(shù)據(jù)量，一次性遷移到另外一套存儲里去那么這個數(shù)據(jù)遷移的步驟，其實涉及到千萬級的數(shù)據(jù)量遷移。你如何保證數(shù)據(jù)遷移的效率？如何保證遷移后的數(shù)據(jù)準確性？在遷移的過程中如何避免影響數(shù)據(jù)庫的性能？像這些問題，其實你平時都應該考慮一下，作為一個技術難點好好闡述一下吧。擅長技術的考察面試官：那你說說你認為自己最擅長最有深度的技術吧？候選人：我好像平時自己用MQ技術比較多一些。面試官：那你說說Kafka、RabbitMQ、RocketMQ幾種MQ的對比，還有他們各自的原理。它們分別如何實現(xiàn)分布式消息隊列架構的，底層的機制都聊一下，對比一下特點以及優(yōu)缺點。建議：大公司一定會考察你的技術深度，一般就是對你平時用的最多，或者最熟悉的技術深入挖掘和考察，看你的技術深度有多深。結果這個同學自己說了MQ，但是對MQ的了解實際上非常的淺薄，深入的東西都說不出來，那么最后一定就是讓面試官很無語了。總結其實這個同學技術底子還是不錯的，包括一些技術的基礎，所以前兩輪面試都是過了的。但是第三輪面試考察的角度都是完全不同的，一下子暴露出來了他的能力缺陷。對自己負責系統(tǒng)的架構演進完全無意識，負責系統(tǒng)的難點從沒思考過，系統(tǒng)涉及