拿下阿里、頭條、滴滴的 offer 後談談面試經驗（下）
在上篇 文章 中，說了java後端面試中常問的基礎問題，而面試除了考察基礎以外，很重要的另一部分是'經驗'，'經驗'泛指以往做過的專案、解決的問題、以及一些開放性問題。
本文主要說兩點：1.專案 2.開放性問題。注意兩篇文章 針對都的是java一線研發崗位 。
更多文章見個人部落格： https://github.com/farmerjohngit/myblog
公眾號（剛申請，之後文章會往上面發）：
先說點題外話，有同學對於上篇文章中有些看法：比如，xxx的底層實現和大多數程式設計師日常開發幾乎無關，有種應付考試的感覺。
我說說我的觀點，
第一，大廠面試 就是 會問jvm、中介軟體、資料庫等原理性的問題， 你要想去大廠 就必須在日常中積累和在面試前準備。簡單粗暴吧？
第二，挺多公司被調侃是面試時造火箭，工作時擰螺絲。這樣的情況是很普遍的，那大廠為什麼喜歡問這些問題？我認為原因有幾點：
1.人才儲備，可能你面試的崗位平時就是搬搬磚，不會涉及到有技術深度的問題，但是對於大公司而言， 必須要確保當出現技術難題時是有人來解決的。 比如很多部門的併發量並不高，但是面試時也會問高併發相關的問題，其目的就是為了確保萬一QPS高起來了，部門裡的人都是有方案、有經驗的。這麼說應該很容易明白吧。
2.篩選人才，如果兩個候選人，一個對於所有的框架都只是會使用，另一個除了會使用以外還清楚框架內部是如何實現的。 如果你是面試官，你會選誰呢？
3.有技術熱情的人 一定 會對某塊領域上有過比較深入研究（可以是jvm、中介軟體、資料庫以及其他）
回到本文正題，先來聊聊專案。
專案
對於簡歷上寫的專案，要從這幾個方面去準備：
-
專案介紹：用最簡潔的語言介紹清楚你的專案，包括專案的背景、方案、用到的關鍵技術、承擔的角色，介紹時不要扯太多細節，讓面試官有個大致瞭解就行，面試官遇到感興趣的點時自然會追問。準備時要考慮到面試官可能完全不瞭解你的業務（比如面試官是做電商的，你的是金融專案）。
-
專案架構：能把專案的架構說清楚，能畫出專案架構圖，能說清楚專案在整個系統中的位置。
-
專案價值：想清楚做這個專案的價值在哪裡？比如讓業務資料提高了XX點、開發效率提升了XX倍。比較忌諱的是直接說老闆讓我做所以我就做了。
-
技術選型：如何做技術選型的？有考慮過哪些技術方案，是什麼讓你選擇了最終的方案？
-
資料：專案帶來的成果，比如業務專案轉化率或點選率提高了XXX。對系統日常資料要有個大概印象，比如叢集的總QPS是什麼量級，大概多少臺機器等，真正參與了的基本上也都知道，就怕是把別人專案說成自己的，這些資料一問就很容易看出來。
-
預案：很多小公司的專案實現功能就好了，對於可用性、一致性等要求沒那麼高。但在面試前準備時需要對專案中有缺陷的點做好預案。舉個例子：資料落庫後要發訊息通知到其他系統，可能你的專案中是：
// 1.資料落庫 writeToDB(); // 2.發訊息 sendMsg();
以上虛擬碼的問題是寫完資料庫後，如果系統掛了（可能是你的系統掛了也可能是訊息中介軟體掛了）導致訊息沒傳送成功，就會有不一致的情況發生。可能你的專案中漏發幾條訊息也沒關係，但是當面試官問到如何保證寫DB和發訊息同時成功或同時失敗時， 你心中要有預案 。
-
規劃（如有）：專案之後要做成什麼樣子，要新增哪些功能，目前有哪些做的不好的地方需要優化。
開放題
下面是我面試被問的比較多的場景題、系統設計方面的題，開放題跟個人經歷也有關係，所以僅供參考。
分散式事務
分散式事務這塊實現方案比較多，網際網路公司很少用2pc這樣的方案，一般都是保證事務的最終一致性，常用事務訊息實現（以及tcc等）。要知道如何利用事務訊息去實現最終一致性，以及事務性訊息是如何實現的。
分散式事務沒有一個絕對的方案，都是因業務場景的不同而不同。舉個例子，電商場景中如何保證訂單落庫和減庫存、鎖券的最終一致性的（不同公司有不同方案，只是列舉個我知道的）。
-
收到使用者下單請求時，在訂單庫中建立一條不可見訂單。
-
同步呼叫減庫存介面，如失敗跳轉到4
-
同步呼叫鎖券介面，成功跳轉到5，失敗跳轉到4
-
傳送一條廢單訊息，收到訊息後回庫存、回券
-
將訂單改為可見
分散式事務的問題，我面試的公司基本上都問過。
如何保證系統高可用
這個一般會結合你的專案來問，比如上游系統請求量過大、依賴的下游非核心應用掛掉、系統出問題如何及時發現等等。主要是從限流、降級、監控、報警、主從備份、容災等角度出發
分散式鎖
實現分散式鎖常見方案有：利用db的唯一鍵、redis、zk等。其中redis實現分佈鎖應該是用的最多的。關於如何用redis實現分散式鎖可以看下這篇 文章 ，當然更嚴謹的實現還是看redis的分散式鎖官方實現： Redisson
快取與DB一致性
我們經常會在DB和應用之間加一層Redis快取，以提高查詢效率，但是當資料發生更新時，如何保證快取與DB的資料一致性呢？可以看看這篇 文章 ，之後我也寫寫阿里是如何保證快取一致性的。
快取擊穿
Redis快取穿透、快取雪崩和快取擊穿幾個問題，在網上都有比較成熟的解決方案了。比如加空value、設定隨機超時時間、加互斥鎖等方式
海量資料處理
如海量日誌資料，提取出某日訪問百度次數最多的那個IP。
一般是hash+歸併、布隆過濾、Map Reduce的思路
這篇 文章 說的很好了
限流
常見限流的方案，如令牌桶演算法，可以看下我之前寫的 來談談限流-從概念到實現 、 來談談限流-RateLimiter原始碼分析
問題排查
一些常見線上問題比如系統的cpu佔用過高、RT突然飆升、頻繁發生full gc、OOM等如何定位並解決？
這主要來自於日常的積累了，排查問題主要依賴監控、日誌、常用工具（top jstack jmap jstat vmstat等）。
End
去年底找工作找了2個多月，中間也經歷了很多坎坷，慶幸的是最後結果還不錯，也祝各位在找工作的朋友拿到滿意的offer。