敖丙：春招字節跳動、蘑菇街四輪面試，分別問了啥？

https://mp.weixin.qq.com/s/xBC1IRr6v8hmIJ9lqCp5pQ

敖丙：春招字節跳動、蘑菇街四輪面試，分別問了啥？

收錄於話題

#面經 171

 

#離職 132

 

#程序員 1567

 

#大廠面經 14

前言

這又是一期讀者的面經分享，很巧的是，他在蘑菇街面了三輪，最後雖然沒過，可是也但願分享出來你們瞅瞅。

我這周可能會單獨作個大廠面試流程的視頻，涉及每一輪的考察點注意事項，若是以爲有必要，能夠留言讓我知道大家想看啥。

面試經歷

一. 11.20 字節跳動一面Java開發，直接掛（恥辱開頭……）

1. 介紹主要項目，怎麼作的；

• 原本想簡要介紹作的業務，但面試官要求詳細介紹，因此二十分鐘都在介紹業務；

• 送命問題：數據量多少？說了實話，實際使用單表1000—10000級別。致使後面基本上面試官根本不想問問題了……

1. 對 Spring 的理解？

2. 對 AOP 的理解？

3. 講一下 Java 的靜態代理和動態代理

而後就沒了，進入問問題環節…… 固然知道已經涼了。面試官說的問題主要在於，在研究所的技術棧仍是太落後，說互聯網的思路和咱們這種人不同。在提了並無什麼實際性的建議以後，結束面試。

收穫：

1. 第一次面試，終於踏出了這一步；

2. 認識到了本身與一線大互聯網公司的差距，待繼續努力；

3. 因爲面試時的準備方向錯誤，在數據量方面的成果無意之失直接判了死刑，並無表達出來真正的性能和準備的內容。之後準備，必定要向大數據量、優化等方向考慮！

4. 表達能力太差。【對…… 的理解？】這種問題一拋出來，嘗試用淺顯易懂的方式

二. 12.04 蘑菇街一面高級 Java 開發

1. 介紹主要項目（大概二十五分鐘左右）；

• 通過上一次失敗，此次梳理了業務的主線，比較熟練的介紹了業務，依舊花了十五分鐘，不過中間穿插了詢問項目方面的問題；

• 詢問問題：

  • (1) 動態模板的數據源從哪兒來？答：資源目錄註冊，經過各個數據服務獲取；

  • (2) 增量數據比較多的狀況下，數據源怎麼處理？答：一方面，數據源一般都是數量比較固定的內容，由各個業務來封裝處理，對於增量數據比較多的狀況，使用動態模板的關聯表模式；另外一方面，數據源數據比較多的時候，一般會使用樹狀結構，數據服務有通用的懶加載處理方式，不會出現性能瓶頸；

  • (3) 動態模板怎麼作數據的邏輯處理？答：動態模板只負責數據的記錄，關於邏輯處理是另一個業務，在簡歷中也有介紹。而後介紹了動態彙總的設計邏輯，大概十分鐘。（說明面試官對作的項目有興趣，而且個人回答已經有了引導性）

  • (4) 若是邏輯處理過程當中並無拋出技術性的異常，而是計算錯誤的異常（相似於 1+1，結果算出來是 3 的錯誤），有沒有什麼處理？（問的是有沒有計算監控功能）答：沒有，只是較爲嚴密的關注了技術上的異常，計算上的錯誤沒有處理。若是真的處理了這種問題，須要經過運維人員在配置頁面中清除 Redis 緩存。

1. 線程池基礎

• 對於一個普通的線程池，coreSize = 5, maxSize = 10，阻塞隊列長度 20，且插入線程是永久執行的，那麼不斷插入線程，線程池中的數量以及對應的反應如何？答：該問題只需瞭解線程池的運做原理便可回答。

1. Spring AOP

• 類內部調用 AOP 問題：a() 方法被 @Around 註解用來輸出日誌，b() 方法沒有 AOP 註解，但 b() 方法內部調用 a() 方法，那麼調用 b() 方法會有怎麼樣的輸出？答：不會有日誌輸出。由於這是類內部調用，而 AOP 是經過代理進行的，類內部調用不會調用代理類，不走代理因此不會有日誌輸出。若是想要有日誌輸出，須要在該類中經過 AopProxy 將代理對象（命名爲 proxy）獲取，而後在 b() 方法中經過 proxy 調用 a() 方法；

1. 爲何臨時決定找工做？答：由於比較熟悉這裏的工做，想找挑戰。

2. 向面試官提問問題。問了問業務內容，技術棧。

三. 12.13 蘑菇街二面高級 Java 開發

總體就是介紹主要項目，時間總共四十分鐘左右。

1. 動態模板

• 動態模板的主線流程已經比較熟練了，該方面流程介紹沒有什麼問題。

• 詢問問題：

  • (1) 動態模板的數據源從哪兒來？答：資源目錄註冊，經過各個數據服務獲取；

  • (2) 動態模板裏面的數據怎麼來？答：用戶添加了模板以後，往裏面錄入數據；

1. 有堆 Dump 和數據庫鏈接池優化經驗，怎麼作的？

2. 動態彙總統計

• 這次面試的絕對雷區。在敘述該部分的時候，我說明了該項目是我設計的。但在描述項目的設計理念時，並無像上次同樣描述的很清楚，反而描述卡頓，中間一度難以進行下去。該部分的設計必定要造成稿子，而且熟練表達，不然拔苗助長。

1. 簡歷中寫了統計的效率優化，具體是怎麼作的呢？

• 兩個出發點進行優化。

• 第一是粒度，咱們有的彙總結果是須要統計多個表的。本來在實現的時候，因爲要求趕時間上線，又有性能要求，因此當時同事寫的時候，在增刪改數據時，咱們的數據服務觸發了訂閱，通知集羣中全部服務數據更新的事件，全部服務又分別發起了五個表的查詢請求，對查詢結果進行處理後存入緩存。

  也就是說，改一次數據，會致使一個服務的五次查詢，若是集羣裏有十個服務，那麼改一次數據就會觸發五十次查詢。可是從業務的角度來看，改了一個表的數據只須要清除該表的緩存便可，其餘四個表的緩存並不須要修改，也就是粒度太粗，因此我第一步是將粒度細化到表的級別。

• 第二是歷史數據。由於咱們的業務場景是容許查詢時間段內的信息，而業務場景又有限制：今天以前的歷史數據是不能修改的。也就是說咱們能夠把歷史數據做爲長時間緩存，今天及其之後的數據做爲短時間緩存，修改數據只觸發短時間緩存的更新。

1. 簡歷上寫了使用 ZK 的分佈式鎖，爲何要選用這種實現方式？使用場景是怎麼樣的？

• 業界分佈式鎖一般狀況下是用 Redis 的 setnx 來實現的，但當時咱們的 Redis 尚未搭建起來，緩存用的是 Memcache；此外，咱們的註冊中心基礎是 ZK，而 ZK 的瞬時順序節點是能夠實現分佈式鎖的功能，因此我就使用了。

• 使用場景：咱們的彙總比較麻煩一些，因此進行一次彙總時間相對較長。雖然一般彙總結果都會放到緩存裏，但若是某一時間緩存中沒有數據，又有大量併發進行彙總結果的查詢，那麼就會引起穿透。因此一方面我和同事搭建了布隆過濾器，防止緩存穿透的情景。

  另外一方面，大量併發同時查詢彙總結果時，因爲服務作了負載均衡，因此集羣中的服務都會接收到請求，緩存中沒有彙總結果，會全部大量服務進行計算。但其實只須要一個服務進行緩存的計算便可，其餘服務的計算屬於資源浪費行爲。
  因此我對一個須要進行彙總的業務使用了分佈式鎖，用查詢條件做爲鎖，獲取到該鎖的服務進行計算，並負責將計算結果置入緩存，其餘服務在嘗試獲取該鎖的時候失敗，返回一個默認的結果，這樣便避免了多餘的計算。

1. 有什麼須要問面試官的問題？問了問業務內容，技術棧。

四. 12.20 蘑菇街三面高級 Java 開發（失敗）

共 40 分鐘左右；

1. 自我介紹

2. 簡歷上寫有 JVM 優化經歷，怎麼作的？

3. 若是設計一個自動監控系統，如何設計？如何實現？

• 因爲在剛纔的 JVM 優化過程，目的是監測某個壓測問題，我介紹了一個經過 JVM 檢查問題緣由的流程。因此面試官提出了該問題。

• 關於自動監控系統的設計，我瞭解有 ES, Logstash, Kibana 的開源套件，有用於日誌收集和監控，但具體我沒有過多瞭解；

• 若是是基於咱們的系統進行實現的話，應該會基於咱們的註冊中心開發一個新的新的監控服務。咱們的註冊中心以 WAR 包的粒度，將對應服務註冊到 ZK 集羣上。因此新的監控服務設計的基本思想，應該是對全部註冊到 ZK 上的服務發送心跳包，收集各服務所在服務器的系統指標、服務運行相關信息；

• 面試官追問：監控哪些服務器和服務的哪些指標？怎麼監控？

  • 答：服務器指標應該監控服務器的 CPU 佔用率、內存使用量、網絡各狀態的鏈接數、網絡帶寬；服務的指標應該監控 Heap 堆的容量、單位時間內 GC 次數、各狀態線程數量；

  • 具體監控的方法我認爲 Java 中應該給出了 API 接口能夠獲取這些信息，由於以前我以前作的的業務操做日誌記錄系統中，有 IP 信息的獲取記錄；當時就是調的 Java 的 API，因此我感受應該有類似的調用方法；

1. 索引如何設計？

• 是因爲我說咱們目前業務的日誌操做監控系統是把數據存到了數據庫中，因此提到了該問題。

• 個人回答：

  • 咱們構建索引時主要針對幾種狀況：

  • 對查詢使用較多的字段考慮構建索引；

  • 可能會比較多使用到篩選、排序的字段；如比較經常使用的時間類型；

  • 有下拉樹惟一標識性質的 ID 字段；

1. ZK 怎麼用的？選舉機制？

• 提到 ZK 是由於我提到咱們的服務註冊到了註冊中心上，註冊中心是用 ZK 爲基礎的；

• 個人項目中接觸到 ZK，主要是我在服務集羣計算的時候爲了節省計算資源，因此使用 ZK 做分佈式鎖；此外 ZK 也用來咱們註冊中心的註冊；

1. 互聯網的架構瞭解哪些？

• 回答了秒殺系統，具體有點忘了。（能夠看看丙丙的歷史文章，秒殺是個人爆文）

1. Spring 的思想？代理如何實現？

• Spring 的思想主要是按照以前寫的博文進行描述的

1. 爲何選擇使用 SSM 框架？爲何使用 Spring boot？

• 使用 SSM 框架的緣由主要是這是整個業界比較通用的框架，並且也是部門的通用框架；

• 使用 Spring Boot 的緣由是，Spring 和 Spring MVC 有不少配置文件，比較繁瑣，而 Spring Boot 將不少配置給集成了進來，使用基於註解的配置方式比較簡單方便。

1. 瞭解的互聯網經常使用的技術棧還有哪些？

• 除了簡歷上寫的，還提到了 Nginx 用於反向代理和負載均衡；若是到達了 Nginx 的反向代理極限，可使用 F5, LVS 進一步擴充併發量的支持，但咱們的併發量沒有到達這種程度，因此沒有再向上了解。

1. 秒殺系統中，緩存與數據庫的一致性如何保證？庫存，網絡波動。

絮叨

能夠看出每一面都不容易哈，你們真的要好好學習呀。

Tips：我有個讀者已經面進咱們公司作個人同事了，丙丙還和他約了一樓咖啡廳喝茶，到時候也會分享出來。