面試官：“專案這麼問，就能把你水分擠幹！”

語言: CN / TW / HK
時間 2023-02-07 05:15:05

作者：小傅哥
部落格：https://bugstack.cn

沉澱、分享、成長，讓自己和他人都能有所收穫！

八股文整的挺好，演算法也刷的夠多，但問到專案就很拉胯。 這可能是現在大部分沒有實際專案經驗的校招生和一直從事邊角料開發的社招生所面臨的問題。

當越來越多的人，想通過取巧的方式找到捷徑來拿Offer。那麼這條線就會被不斷的拉齊，直到越來越多的人都成了八股和刷題高手後，招聘的方式也會改變。—— 面試官不在直接問八股，而是從專案中提問，反向映射出技術和演算法問題。

剛你說峰值QPS3000，RT1.2s，但你簡歷裡寫這個專案雙機房部署4臺例項🤔？ 面試官會通過一些實際場景來了解你是否做過專案，在專案中遇到什麼樣的問題，你是怎麼解決的，使用了什麼技術方案。而這樣的提問必須是求職者真的做過這些，否則很難把背過的八股題和實際專案聯絡起來。

所以小傅哥以多年的程式設計經驗和落地能力，通過一個實際專案來給大家講解下都會遇到哪類面試問題，該如何回答。你可以把這當成一場模擬面試

一、簡歷：專案經驗

這裡以小傅哥的《Lottery 抽獎系統 - 基於領域驅動設計的四層架構實踐》專案所體現到簡歷中的案例進行展示，如果想了解這個專案，也可以先看影片介紹。

之所以選擇這樣一個專案開發，是抽獎營銷活動類系統可以適應的場景更全面，例如；電商、出行、外賣、旅遊、汽車等，在促活、留存、拉新上，都可以使用抽獎系統。因為抽獎系統是工具系統，可以掛到任何其他符合場景的系統上來講解。而且抽獎系統的架構、設計、實現都較為複雜，有東西可以聊，屬於尖刀隊。類似 Java 中的 HashMap 隨時可以拿出來剛以下。

所以抽獎系統不存在說：“你們組多少人都做抽獎”，因為所有場景，只要符合就會有抽獎和活動，如果一個公司的產品沒有營銷業務這條線，那麼一種是場景不符合，另外一種是壓根沒這個體量。所以只要你把抽獎合理的放到一個系統下，串聯好你的話術能自圓其說，之後你就可以用抽獎去面試了。

  • 專案名稱：營銷活動平臺 – Lottery 微服務抽獎系統
  • 系統架構：以 DDD 領域驅動設計開發，微服務拆分的分散式系統架構
  • 核心技術：SpringBoot、Mybatis、Dubbo、MQ、MySQL、XDB-Router、ES、ZK
  • 專案描述：Lottery 抽獎系統，是營銷活動平臺中的一個重要微服務，用於滿足C端人群拉新、促活、留存的系統。系統根據微服務的界限上下文，運用抽象、分治和 DDD 知識，拆解服務邊界、凝練領域服務功能。以圍繞抽獎服務，解耦功能流程，建設領域服務，包括：規則引擎、抽獎策略、活動玩法、獎品發放等。來滿足業務產品快速迭代上線的訴求，減低研發持續投入成本，提升交付效率。
  • 我的職責：
  • 構建以 DDD 分層結構的處理方式，搭建整個抽獎系統架構。
  • 運用設計原則和工廠、代理、模板、組合、策略等設計模式的綜合使用，搭建和開發方便維護和易於迭代的系統工程。
  • 鑑於系統內有較多的規則策略過濾，包括：准入、人群、風控、A/BTest等訴求，以適合系統規模可快速開發和使用的方式，搭建去中心化的量化人群規則引擎元件，通過業務訴求對 Logic 的擴充套件和內建引擎執行器的使用，完成自由組合的人群過濾服務。降低共性功能重複開發所帶來的成本問題，提供研發效率。
  • 應實際秒殺峰值場景 TPS 2000 ~ 3000 的訴求，開發統一路由元件，不僅可以滿足差異化不同欄位的分庫和分表組合，以及 Redis 庫存分片和秒殺滑動庫存分塊，開發統一路由 XDB-Router 的 SpringBoot Starter 技術元件。此套元件經歷數次大促活動場景，支援橫向擴充套件，可以滿足業務規模的快速增長。

二、模擬：面試問題

1. 資料質疑

面試官一定會通過簡歷的專案描述，首先對你所描述內容的一個質疑。因為畢竟面試官是不瞭解你的，所以會通過質疑的方式來判斷這樣一個專案是否能有因有果，承上啟下，自圓其說。

1.1 這個營銷系統是之前就有，你去接手了。還是你從0到1構建的

  • 題目：這個營銷系統是之前就有，你去接手了。還是你從0到1構建的。
  • 解答：如果是公司的專案，有幾種情況；
  • 原來有一個抽獎系統，但設計實現上不好滿足業務需求，程式碼維護成本越來越高。所以開始重新架構設計從0開始開發。
  • 進入公司後，剛是公司開始準備在核心業務上做營銷拉量的時候，所以從0開始搭建開發。這個過程中做了大量的技術調研和架構設計評審。
  • 進入公司後是一個已經存在的專案，為了更好的支撐業務快速迭代，對系統進行重構。設計了新的模組；規則引擎、策略演算法【可以多幾種抽獎方式】。
  • 畫外：幾種不同方式的回答，也會牽扯到後續提問中的一些問題點。別回答回答著，前面說從0搭建的，後面解答不上來的問題，又說是其他同事之前遺留的。

1.2 線上是部署的機器數量和規格是什麼樣，幾核幾G的機器，部署了多少臺？

  • 題目：線上是部署的機器數量和規格是什麼樣，幾核幾G的機器，部署了多少臺？
  • 解答：
    1. 這個回答到不難，但你所描述出的機器數量會牽扯到系統所能承載的峰值流量，比如；通過雙機房部署了4臺4核8G的伺服器。
    2. 同時這裡也可能提到伺服器頻寬問題，像網際網路大廠中至少是千兆網絡卡，核心應用都在萬兆網絡卡。以10M公網寬頻舉例，下載速度在1.25M/秒 = 1280KB/秒。如果一個網站載入是30KB，那麼 1280/30 ≈ 42，也就是10M頻寬能支撐42個併發在1秒開啟。所以通過你提到的這些資料，面試官也是能粗略估計出應該能在多少流量。

1.3 簡歷上系統峰值QPS3000，RT1.2s，但你剛說是雙機房部署了4臺應用例項，這個資料準確嗎？

  • 題目：簡歷上系統峰值QPS3000，RT1.2s，但你剛說是雙機房部署了4臺應用例項，這個資料準確嗎？
  • 解答：
    1. 這裡有一個基本的公式，併發數 = QPS * RT【響應時間/秒】，那麼 QPS 3000 * 1.2秒 = 3600個併發。4臺應用例項 * 150【預設tomcat配置】 = 600 併發。雖然這是評估值，甚至 tomcat 也可以配置到 200個併發，但這個值仍與 3600 有較大差異，所以會被質疑。
    2. 這裡還會牽扯到資料庫的配置，資料庫總連線數是多少，每臺機器應用例項分配的連線數是多少。所有佔用的連線數一定是小於總連線數的，否則連線池被打滿，可能會出現幾萬毫秒的慢查詢，直至拖垮資料庫，讓整個系統崩潰。
    3. 再舉例個關於流量評估的場景【28法則】，可以根據這個評估自己的系統QPS；系統有1000萬用戶，那麼每天來點選頁面的佔比20%，也就是200萬用戶訪問。假設平均每個使用者點選50次，那麼總用有1億的PV。一天24個小時，平均活躍時間段算在5個小時內【24*20%】，那麼5個小時預計有8000萬點擊，也就是平均每秒4500個請求。4500是一個均值，按照電商類峰值的話，一般是3~4倍均值量，也就是5個小時每秒18000個請求【QPS=1.8萬】
    4. 對於一個真實場景的系統來說，所有的評估資料都只能作為壓測配置參考資料。因為介面的邏輯不同，所以也可能倒置併發數的高低。所以像各大網際網路在大促前要進行介面的血脈梳理和伺服器配置調整，並進行N輪壓測和優化，這樣才能拿到一個準確的資料。

2. 架構設計

2.1 為什麼使用DDD，主要用於解決什麼問題？

  • 題目：為什麼使用DDD，主要用於解決什麼問題？
  • 解答：從軟體的複雜度和需求迭代次數來看，最開始的開發成本並不是最大的。因為在長週期迭代中，後期的維護成本才是最大的。那麼對於這樣的系統來說，更易維護就顯得非常重要。而 DDD 恰好以領域為核心設計，分拆業務邏輯為獨立的模組，在通過應用層編排的方式對外提供服務，這樣更加容易擴充套件。

2.2 DDD架構和MVC架構有什麼區別？

  • 題目：DDD架構和MVC架構有什麼區別？

  • 解答：

  • MVC：更偏向與資料建模實現，由資料呼叫驅動，所以也就引申出的DAO、PO、VO類會隨著專案開發不斷的膨脹，不易於迭代和維護。

  • DDD：以業務流程提煉領域模型為驅動，設計和實現模組開發，在一個領域中包含mode物件、倉儲資料、服務實現，也更注重設計模式的使用，否則實現的DDD徒有其表更多的只是歸類了 DAO、PO、VO 物件。

2.3 抽獎系統的核心域，支撐域和通用域分別對應哪些呢？

  • 題目：抽獎系統的核心域，支撐域和通用域分別對應哪些呢？

  • 解答：

  • 不同視角下其實解讀為不同的域，其實也都可以【你這樣列舉也ok】。一般我們把主線流程成為核心領域，用於支撐主線流程的算作支撐領域或者核心子域。

  • 那麼我們現在以抽獎為整個路線看，需要有3個步驟；參與、執行、兌現。也就是對應的活動、抽獎、獎品。而規則引擎其實沒有也能完成抽獎，並且規則引擎也可以適用於其他模組下，所以它可以被看做是通用域/核心子領域。

3. 技術深度

3.1 近期用抽獎專案去面試，老被問到有沒有線上出現CPU或記憶體飆高等線上問題，讓我說說具體的場景以及如何解決的。

  • 事故級別：P0
  • 事故判責：營銷活動推廣使用者較多，影響範圍較大，研發整改程式碼並做覆盤。
  • 事故名稱：秒殺方案獨佔競態實現問題
  • 事故現象：線上監控突然報警，CPU佔用高，拖垮整個服務。使用者看到可以購買，但只要一點下單就活動太火爆，換個小手試試。造成了大量客訴，緊急下線活動排查。
  • 事故描述：這個一個商品活動秒殺的實現方案，最開始的設計是基於一個活動號ID進行鎖定，秒殺時鎖定這個ID，使用者購買完後就進行釋放。但在大量使用者搶購時，出現了秒殺分散式鎖後的業務邏輯處理中發生異常，釋放鎖失敗。導致所有的使用者都不能再拿到鎖，也就造成了有商品但不能下單的問題。 事故處理：優化獨佔競態為分段靜態，將活動ID+庫存編號作為動態鎖標識。當前秒殺的使用者如果發生鎖失敗那麼後面的使用者可以繼續秒殺不受影響。而失敗的鎖會有worker進行補償恢復，那麼最終會避免超賣以及不能售賣。
  • 學習總結： 核心的技術實現需要經過大量的資料驗證以及壓測，否則各個場景下很難評估是否會有風險。當然這也不是唯一的實現方案，可以根據不同的場景有不同的實現處理。

3.2 假定新增加抽獎碼是隨機的6位數，也就是有1-999999這麼多的抽籤碼，使用者每次獲取都是隨機的抽獎碼，最後統一開獎。怎麼在你的系統中處理。

  1. 提供一個記錄抽獎碼資料庫表，按照你目前的量還不需要分庫分表。
  2. 生成的隨機碼記錄到抽獎表，同時記錄一個自增的數字，這樣就能知道從1到n有多個隨機抽獎碼。
  3. 每個使用者身上記錄抽獎碼，可以是一個也可以是多個，記錄在自己身上。
  4. 抽獎開始時候，不用抽獎碼，用的是1~n的範圍，基於這些範圍比如1-10000，從中隨機去除10個，那麼這個10個數字對應的碼就是抽獎碼，在用抽獎碼匹配到個人身上，修改狀態為中獎。

3.3 因為員工誤刪了redis已使用庫存key，出現活動庫存超賣怎麼解決？

Lottery 的設計把這事給辦了； 1. Lottery 採用的是滑塊鎖，按照庫存編號自動成，如【key_1、key_2、key_3、key_4、...】這些key都被秒殺到的使用者 setNx 加鎖了。 2. 如果key被刪，則會從0開始計數 incr 但計數後，又會生成 key_1 加鎖，可是這個key已經被加鎖過，所以會告訴衝突。直到key incr 到當前為加鎖的 key_n 時才能被正常購買。

4. 其他問題

4.1 把抽獎專案重新做一邊，有哪些方面可以做的更好。

舉例回答吧，因時因地，可能有很多答法。最重要的就是自圓其說，別挖完坑不填；

把抽獎專案重新做一邊，有哪些方面可以做的更好：

  1. 其實在我們最開始承接專案做架構設計和工程實現時，就已經做了大量的調研、設計和評審。包括；工程的架構、需求的迭代、後續的維護以及整個系統的擴充套件性是否能滿足業務未來3年的發展等，這些方面都做了很多的考慮。那麼當然也不是說我們的系統服務已經完美了，它只是在當下情況下貼近真實情況的最佳方案，不過渡設計的同時也滿足系統的發展。
  2. 但就業務的適合市場的發展對應到產品的更新迭代速度來說，後續我們在做抽獎系統的時候，會更希望把每個服務做成原子化的可編排領域服務，配合低程式碼平臺進行拖拉配置的方式上線各類活動。因為目前我們的活動是越來越多的，但除了基礎底層服務以外，也有不少的開發工作，希望把這部分重複工作，儘可能通過配置來實現，做成一些開放平臺SDK自動化生成的方式來處理。

4.2 專案遇到最大的挑戰是什麼。

  1. 在工期壓榨下，滿足於當下快速上線還為做出符合未來預期的可持續性系統，是最大的挑戰。
  2. 怎麼與產品溝通、怎麼和領導說明、怎麼完成交付，這些在專案初期時候做了不小的溝通。才得以讓目前的專案落地。我個人也在這裡成長很多。

三、彙總：其他問題

綜上像這樣的實際專案問題，只有做過專案才可能回答的出來。如果滿手都是學生管理系統、使用者管理系統、圖書管理系統等，那麼可能還沒到面試階段就已經被Pass了。所以講屁話是沒有用的，只有硬核專案 + 時間投入 = 工作機會，即使這樣的專案有些學習難度，那麼也是值得花時間折騰的。

除了以上小傅哥列舉的問題以外，其實還有很多整理出來的問題，這裡截圖給大家看下。面試問題地址：https://bugstack.cn/md/zsxq/material/interview.html

四、加入：實戰專案

如果你手裡確實沒有什麼像樣的實戰專案能擺到簡歷裡給面試官看。那麼我非常建議加入小傅哥的知識星球。因為在知識星球裡，小傅哥提供了：《Lottery-抽獎系統》、《API閘道器》、《IM通訊》、《手寫MyBatis》以及各類技術小冊，這些專案學習完任何一個，都能和麵試官聊到心花怒放，知道你是個有技術深度值得招聘進來的小夥。

專案地址：https://bugstack.cn/md/zsxq/introduce.html

  1. 星球內的服務和實戰專案都是小傅哥本人提供和原創，相信能夠給大家帶來超過該價格的價值 。舉個例子，漸進式手把手帶大家做進大廠才可能看得見的專案、有筆記有原始碼、有問題可以提，這比單獨買一個課程或一套原始碼要值得多。其實都不到大城市一節補習班的錢，哪怕把我的課程時長換算成培訓機構的課時，也是便宜的超級多。
  2. 持續的內容創作 + 回答問題 + 知識星球的運營(簡歷批閱、就業指導、架構設計) 需要小傅哥每個早上6點-8點以及週末/假期持續維護。也希望加入星球的同學都是真的下定了決心想要進步，而不是像免費的交流群和社群一樣 “閒聊扯淡”。
  3. 加入進來的同學能夠利用好星球來堅持學習。如果這個星球真的幫助你達成了目標（比如晉升加了薪、跳槽諾了坑、校招進了廠），回過頭來你會發現，這絕對是你 最值得的一筆投資 ！（免費的東西往往不會珍惜，別問我為什麼知道！）
  4. 星球仍將隨著人數和專案的增加會每次提價，感謝理解！—— 但已付費的加入的使用者，續費5折，相當於只續費小傅哥的服務和新專案費用，沒有什麼比這更爽的了！如果當年有人這樣對我，我會買它個10年！
「」
「」