2018年秋招那會兒我把小米服務端工程師的筆試主觀題從頭到尾啃了一遍。整張卷子沒有選擇題全是需要現場組織語言、畫架構、寫方案的設計題。說實話那是我秋招遇到的第一份“考思路比考記憶多”的卷子。現在回看這套主觀題其實把服務端開發最核心的知識域都串起來了高并發設計、網絡鏈路、緩存一致性、海量數據處理。本文把這套主觀題的完整復盤寫出來每道題都拆到考察點、答題框架、追問預案三個層次適合正在準備后端或服務端校招崗位的讀者也適合剛入行、想系統建立服務端知識體系的朋友收藏。1. 主觀題全景小米服務端校招到底考什么1.1 主觀題和客觀題最大的區別在哪客觀題考“你知道不知道”主觀題考“你會不會用”。服務端工程師的主觀題尤其明顯它不會直接問你“TCP三次握手是哪三次”而是給你一個業務場景比如“設計一個支持高并發的短鏈接服務”讓你從零開始把它講清楚。這時候面試官和判卷人真正想看的不是你背了多少八股而是三個維度。第一是完整性。同樣一道短URL設計題有人只會說“用哈希生成短碼”有人能從發號器、存儲選型、緩存策略、重定向狀態碼、壓測預估講到監控報警。覆蓋的鏈路越完整說明你對服務端系統的全局認知越強。第二是取舍感。系統設計里沒有“銀彈”只有場景匹配。比如短鏈接的讀請求遠多于寫請求就適合緩存和只讀從庫秒殺場景的寫請求集中在熱點商品上就適合隊列削峰和庫存前置。能不能說清楚為什么在這個場景選這個方案是主觀題拉開分差的關鍵。第三是表達能力。方案在腦子里是一團亂麻還是能按“需求分析、量級估算、架構設計、核心細節、追問預案”的順序講出來直接決定了判卷人對你工程素養的判斷。我見過不少技術水平不差的人因為表達混亂丟了分非常可惜。1.2 當年這套題覆蓋的知識域速覽主觀題合集里一共六道題每道都對應一個獨立的知識域。我按當年的題目順序整理成了下面這個對照表方便后續逐個展開。題目考察方向核心知識點設計一個短URL服務系統設計發號器、Base62編碼、哈希沖突、301與302設計秒殺系統的服務端方案高并發限流算法、MQ削峰、庫存扣減、樂觀鎖從輸入URL到頁面展示發生了什么網絡綜合DNS、TCP、HTTP、瀏覽器渲染、緩存緩存與數據庫一致性怎么保證分布式Cache Aside、延遲雙刪、binlog補償從海量日志中統計訪問次數Top100的IP海量數據分而治之、Hash分片、堆排序服務端接口冪等性怎么設計接口設計冪等鍵、唯一索引、狀態機、重試機制這套題放到現在來看也完全不過時。這幾年各大廠的校招面經翻來翻去題目形態可能改了包裝但內核依然是這六塊。所以與其到處找題庫刷數量不如把這幾類問題的思考框架真正建立起來。我當時拿到這套題之后的第一反應是題目本身不難難的是在有限時間內把答案組織得足夠完整。這也是主觀題最磨人的地方。2. 高頻系統設計題短URL服務怎么一步步拆解2.1 拿到系統設計題先別急著寫方案短URL服務當年排在主觀題第一位也是幾乎所有服務端面試里最高頻的系統設計題目。題目一般這么描述設計一個短鏈接服務可以把長鏈接變成短鏈接用戶訪問短鏈接時能跳轉到原始長鏈接要求支撐海量訪問數據不能丟。這道題最忌諱的就是上來直接畫架構圖。正確的打開方式先拆需求。核心功能只有兩個生成短碼、跳轉還原。非功能需求有三個高可用、高性能、數據可靠。接下來做量級估算比如每天新增短鏈接1000萬條那就意味著一年存儲量在36.5億條左右MySQL只要設計好分表完全能扛住寫入訪問量的讀請求遠大于寫請求比例粗略按100比1來算峰值QPS可能到幾十萬甚至上百萬這時候必須上緩存。量級估算的意義在于它會倒逼你做出合理的技術選型。如果你沒做估算就直接說“用Redis存所有短鏈接”這是錯誤的——因為Redis內存太貴不劃算。估算完之后你會發現正確的存儲選型應該是“全量數據放MySQL熱點映射放Redis”這樣成本和性能都是可控的。2.2 短碼生成方案對比發號器為什么是首選短碼怎么生成是這道題的第一個核心決策點。市面上常見的方案有哈希、隨機數和發號器三種我當年在面試中把三種都講了最后給出了選型結論。哈希方案的思路是把原始長URL取MD5或CRC32值截取前幾位作為短碼。優點是本地計算快、不需要額外存儲依賴但缺點是哈希沖突不可控一旦兩個不同長URL算出相同短碼要么拒絕生成要么重試重算實現起來麻煩而且短碼長度也不好控制。隨機數方案是隨機生成一組字符作為短碼實現最簡單但每次生成都要查一次數據庫確認沒有撞碼生成效率低存儲的短碼索引也大。發號器方案則完全不同用數據庫自增ID或分布式ID生成器拿到一個全局遞增的ID然后把這個ID做Base62編碼。因為ID本身是唯一的編碼后的短碼天然不會沖突同時還能反向解碼還原ID連索引查詢都省了。發號器方案之所以是首選是因為它同時解決了唯一性、短碼長度和查詢效率三個問題。下面這個Python示例是我當年整理筆記時寫的展示了最核心的Base62編碼邏輯。ALPHABET 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ def base62_encode(num): if num 0: return ALPHABET[0] res [] while num 0: num, rem divmod(num, 62) res.append(ALPHABET[rem]) return .join(reversed(res)) def base62_decode(code): num 0 for ch in code: num num * 62 ALPHABET.index(ch) return num注意看編碼結果ID等于10000000時編碼出來的短碼長度只有4到5位比純隨機字符串短得多用戶體驗更好。而解碼時只需要遍歷字符串逐位計算時間復雜度是O(n)性能極高。2.3 存儲、緩存和重定向的細節別漏掉短碼方案定了之后存儲表結構基本是固定的id、short_code、original_url、created_at其中short_code加唯一索引。這里有個細節如果直接用唯一的short_code作為主鍵那在數據量大之后分庫分表的鍵選擇會更方便可以把short_code作為分片鍵這樣同一個短碼的查詢永遠只落在同一個分片上。查詢跳轉的流程是典型的Cache Aside模式先查Redis命中直接返回長URL沒有命中就回源MySQL查詢查到后回填Redis并返回Redis里查不到且數據庫也沒有就返回404。回填的時候記得設置過期時間比如一到兩天避免冷數據長期占用內存。重定向狀態碼選301還是302是這道題里最經典的追問點。301是永久重定向瀏覽器會緩存跳轉結果第二次訪問同一個短鏈接時瀏覽器干脆不發請求直接跳到長URL服務端壓力小但拿不到點擊量數據。302是臨時重定向每次訪問都會請求服務端方便統計點擊數據但會給服務端帶來更多請求量。業務方如果對點擊數據敏感比如營銷活動想看轉化率就選302如果完全不在意統計只求省資源301也可以。面試里建議說“大多數業務場景選302因為統計優先”。2.4 追問環節的高頻深挖點面試官不會滿足于你講完主體方案大概率會追問三個方向。第一個方向是并發安全發號器的ID并發重復怎么辦答案是數據庫自增ID天然保證并發唯一如果擔心數據庫單點瓶頸可以用號段模式一次性從數據庫取一批ID到內存比如每次取1萬個發完再去取數據庫壓力直接降幾個數量級。第二個方向是安全問題短碼只有幾個字符暴力枚舉怎么辦可以給短碼加隨機位打散規律性同時對同一個IP的訪問頻率做限流防止惡意遍歷。第三個方向是雪崩問題緩存大面積失效怎么辦Redis的key要設置合理過期時間加隨機偏移數據庫層要有降級預案比如限制只允許一部分節點回源其他節點直接返回提示頁。這道題只要把“需求拆解、量級估算、發號器、Cache Aside、301/302、追問預案”這六步完整走一遍基本就能拿到基準以上的分數。它的套路其實就是所有系統設計題的通用套路。3. 高并發場景題秒殺系統的服務端方案怎么答3.1 秒殺的本質不是賣貨是流量管控秒殺是服務端面試里另一道經久不衰的場景題。題目通常這樣出某個商品庫存1萬件開放搶購后瞬間涌入百萬級請求請設計服務端方案要求不能超賣、不能崩潰、用戶體驗盡量平滑。拿到這種題第一個要扭轉的思維是不要試圖讓所有請求都成功。秒殺系統的本質是一次大規模的流量管控1萬件庫存對應的有效請求只有1萬個剩下的99萬個請求注定要失敗系統要做的不是讓它們全部進入業務流程而是讓絕大部分請求在入口處就被攔截掉。這個思維可以泛化到所有服務端高并發場景昂貴資源數據庫、磁盤IO、下游第三方接口永遠不應該直接暴露在全部流量之下。我當時把這套思路總結成三層攔截模型網關層擋掉非法請求和超出閾值的流量應用層限流和排隊數據層只用真正有資格的請求去觸碰庫存。很多方案翻車往往是因為直接把用戶請求打到了數據層導致數據庫連接池被瞬間打滿整個服務連帶宕機。3.2 服務端限流算法選型從固定窗口到令牌桶限流是秒殺系統的地基也是服務端接口保護的基本功。面試中你至少要能講清楚四種限流算法的適用場景和缺陷。固定窗口計數器是最簡單的方式每秒一個窗口窗口內計數超過閾值直接拒絕。問題在于臨界突變0到1秒的窗口和1到2秒的窗口各自允許100個請求那在臨界點前后可能瞬間放過200個請求流量不夠平滑。滑動窗口在固定窗口的基礎上把窗口細分成多個小格子滾動統計能有效消除臨界突變但實現上要維護時間輪占用更多內存。漏桶算法像一個漏斗請求先進入桶里以固定速率流出不管上游流量多大下游拿到的始終是勻速的。它適合保護下游系統但代價是請求延遲被拉高。令牌桶算法則是以固定速率往桶里放令牌請求來的時候必須拿到令牌才能通過桶里最多攢滿一定數量的令牌所以它允許一定程度的突發流量性能好也是實際工程里用得最多的方案。下面是一個基于Redis計數器做簡單限流的偽代碼生產環境可以換成Lua腳本保證原子性。// 基于Redis INCR的固定窗口限流偽代碼 String key rate_limit: System.currentTimeMillis() / 1000; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1) { redisTemplate.expire(key, 2, TimeUnit.SECONDS); } if (count ! null count MAX_QPS_PER_WORKER) { throw new BizException(訪問過于頻繁請稍后再試); }面試中可以這樣總結選型并發量小、實現簡單選固定窗口下游保護優先選漏桶既要扛突發流量又要穩定輸出選令牌桶。秒殺場景下接口層用令牌桶下單入口用隊列削峰兩者配合。3.3 庫存扣減怎么避免超賣限流只是擋掉了大部分流量真正處理剩余的“有效請求”時最怕的是超賣。庫存扣減的經典方案是數據庫行鎖SQL長這樣UPDATE stock SET count count - 1 WHERE product_id ? AND count 0;關鍵在于count 0這個條件在并發事務中MySQL的行鎖會讓同一行記錄的操作串行化只有一個事務能把count減到0其他事務因為條件不滿足更新行數為0不會真正扣減所以天然能防超賣。但它的缺點是大量請求同時競爭同一行的鎖數據庫壓力非常大吞吐量受限。另一種思路是樂觀鎖。給庫存表加version字段更新時帶上版本號版本號變了就說明被別人改過重試或返回失敗。秒殺場景下庫存是熱點數據樂觀鎖重試次數會非常多體驗反而不好所以更推薦的做法是Redis預扣減。所謂預扣減就是先把庫存同步到Redis用DECR命令原子減一減完大于等于0才算成功然后立刻返回用戶“搶購成功”。真正的數據庫庫存扣減通過MQ異步消息來完成而不是讓用戶請求同步等待。Redis的單線程模型天然串行化性能遠高于數據庫行鎖能抗住幾十萬的扣減QPS。這里要注意的是Redis扣減成功但異步消息投遞失敗會造成Redis和數據庫庫存不一致所以必須引入對賬任務定期比對兩邊庫存發現差異就補償。3.4 秒殺方案的通用回答模板這道題回答時我建議按下面這個順序來。第一需求分析明確庫存量、預估峰值QPS、超賣容忍度。第二前端攔截按鈕置灰、動態令牌先把腳本刷量擋掉。第三網關層限流按用戶維度、IP維度雙重限制。第四應用層排隊把真正進入下單流程的請求壓進MQ用隊列長度控制數據庫壓力。第五庫存扣減Redis預扣減加數據庫最終扣減。第六兜底方案對賬補償、人工介入。這套模板不只是為秒殺準備的凡是涉及高并發寫入的系統都可以參考。4. 網絡綜合題從輸入URL到頁面展示的完整鏈路4.1 全鏈路七層梳理這道題幾乎是服務端面試的必考題因為它能一次性考察網絡基礎、操作系統、Web服務、瀏覽器原理多個領域。題目描述很簡短用戶在瀏覽器輸入一個URL按下回車到頁面完整展示中間發生了什么。完整的回答鏈路我習慣分成八個階段。第一階段是URL解析瀏覽器提取協議、域名、端口、路徑和查詢參數。第二階段是緩存查找瀏覽器緩存、系統緩存、路由器緩存甚至DNS服務器緩存都查一遍有沒有對應的IP。第三階段是DNS解析把域名解析成IP這個過程中會涉及本地DNS服務器、根DNS服務器、頂級域名服務器、權威域名服務器的遞歸或迭代查詢。第四階段是TCP連接建立三次握手。第五階段是發送HTTP請求如果用了HTTPS還要先經歷TLS握手協商密鑰。第六階段是服務端處理請求經過負載均衡、應用邏輯、數據庫查詢后返回響應。第七階段是瀏覽器解析HTML、CSS、JavaScript構建DOM樹和渲染樹。第八階段是連接關閉或者保持長連接復用。這道題能拿高分的要點不在于把八階段背下來而在于每個階段都能講出幾個“別人不常提的細節”。4.2 每個階段容易忽略的細節DNS階段容易被忽略的點是緩存和TTL。DNS查詢結果并不是每次都全鏈路遞歸每一層都有緩存緩存時間由TTL控制所以一次域名解析可能只要幾毫秒也可能因為緩存過期需要重新走完整遞歸鏈路而耗時幾百毫秒。面試官如果問“為什么首次訪問慢、后續訪問快”答案就在這里。TCP階段最經典的問題是為什么三次握手而不是兩次。答案很簡單三次握手能讓雙方都確認自己的發送能力和接收能力是正常的。第一次握手客戶端確認自己發送能力正常、服務端接收正常第二次握手服務端確認自己發送能力正常、客戶端接收正常第三次握手客戶端再確認一次雙方收發都正常順便告訴服務端可以開始發數據了。兩次握手的話服務端無法確認客戶端的接收能力。HTTP階段值得展開的是協議演進。HTTP/1.1引入了Keep-Alive長連接和管線化但管線化存在隊頭阻塞問題前一個請求不結束后一個響應就得等著。HTTP/2通過多路復用解決了HTTP層的隊頭阻塞但TCP層的隊頭阻塞依然存在。HTTP/3干脆改用基于UDP的QUIC協議徹底繞開了TCP層的隊頭阻塞問題。這一段如果能在面試中主動講出來面試官對你的網絡功底會明顯加分。還有HTTPS。如果URL是https開頭那在TCP連接建立之后還要額外做TLS握手客戶端發送支持的加密套件列表服務端返回證書客戶端驗證證書鏈并生成會話密鑰雙方協商加密方案。這個環節最容易答漏但它恰恰是現代服務端最基礎的安全能力。4.3 面試官的挖坑方式長什么樣這類題目答完主體鏈路之后面試官一般會沿著細節繼續追問。比如輸入一個不存在的域名會怎樣答案是DNS解析失敗瀏覽器顯示“無法訪問該網站”服務端側根本收不到任何請求所以排障第一步應該先確認域名解析記錄有沒有配錯。再比如如果目標服務器的端口根本沒有進程監聽客戶端會收到什么答案是RST包TCP連接直接被重置而不是正常的四次揮手FIN包。這個問題的意義在于區分“端口不可達”和“連接正常關閉”是兩種完全不同的狀態。又比如為什么頁面里有大量圖片資源時HTTP/1.1需要建立多個連接因為HTTP/1.1的Keep-Alive雖然是長連接但同一個連接同一時刻只能處理一個請求瀏覽器為了并行加載資源只能開多個TCP連接而HTTP/2的多路復用允許在一個連接上同時并發多個請求。這些問題每個都是知識點不需要猜題只要把鏈路理解透了怎么問都能接住。5. 緩存與數據庫一致性判斷依據和工程取舍5.1 緩存三大問題穿透、擊穿、雪崩服務端面試聊緩存繞不開這三個經典問題。穿透是指用戶查詢一個根本不存在的數據緩存里沒有數據庫里也沒有請求每次都穿透到數據庫如果被惡意腳本大量發起數據庫響應就會被打爆。解決辦法是緩存空值給不存在的key也寫一個短暫的空緩存或者用布隆過濾器在請求到達數據庫之前判斷key是否存在不存在直接返回。擊穿是指某個熱點key在過期的一瞬間大量請求同時發現緩存沒有數據一起打到數據庫上。解決辦法是熱點key不設置過期時間或者把過期時間拉長同時用后臺任務異步更新緩存保證舊數據在過期后依然可以被請求命中而不是讓請求穿透。雪崩是指大量key在同一時間段內集中過期導致數據庫瞬間承受大量請求。解決辦法很簡單每個key的過期時間加一個隨機偏移量比如在五天到七天之間隨機讓過期時間自然錯峰。這三大問題在答題時很多人會混淆我的記憶方法是穿透是不存在的key擊穿是單個熱點key過期雪崩是批量key過期。三個問題對應三個解決思路別混。5.2 Cache Aside模式與延遲雙刪的細節緩存讀寫策略里Cache Aside是最主流的一種也是服務端日常開發中最常被問到的一種。讀流程是先查緩存命中直接返回沒命中就查數據庫把結果回填緩存再返回。寫流程是先更新數據庫再刪除緩存。為什么是刪除而不是更新緩存原因有兩層。第一層更新緩存成本高于刪除緩存。更新緩存要重新序列化對象、寫Redis而且可能寫入一個之后永遠不會被讀到的冷數據刪除只是O(1)操作。第二層并發環境下更新緩存容易產生舊值覆蓋新值的問題。兩個請求同時寫同一個數據后到的請求先寫了數據庫前到的請求后寫了緩存緩存里存的實際上是舊值這比刪除緩存引發的不一致更麻煩。那么先刪緩存再更新數據庫行不行也不行。假設請求A刪除緩存后還沒來得及更新數據庫請求B來讀緩存發現沒數據回源數據庫讀到了舊值并回填緩存這時請求A才更新數據庫緩存里就永遠留下了舊值。所以標準做法是先更庫再刪緩存。后來又有人提出延遲雙刪先刪緩存、更新數據庫、等幾百毫秒再刪一次緩存把中間窗口期被重新填進去的舊值清掉。延遲雙刪能降低不一致概率但在極端情況下如果第二次刪除失敗該不一致還是不一致所以更可靠的方案是訂閱數據庫binlog解析出變更事件后刪除對應緩存刪除失敗就重試。這個方案復雜度高但工程上最可靠。5.3 一致性要求的業務分級和選型邏輯面試中說到緩存一致性不要只背方案要能讓面試官看到你的取舍判斷。一致性要求是分級的。普通業務數據比如用戶昵稱、文章閱讀數能接受秒級別的暫時不一致用Cache Aside就夠了。強一致要求的數據比如支付狀態、訂單狀態緩存只讀不寫或者直接不走緩存所有讀寫都落數據庫。中間態的數據比如購物車內容允許短時間弱一致可以用延遲雙刪或者binlog補償。還有一個容易被忽略的維度是讀寫比例。同一個數據如果讀多寫少緩存命中率很高先更庫再刪緩存的代價就很小如果寫非常頻繁那每次寫都要刪一次緩存下一次讀又必然miss回源緩存反而成了負擔。這種情況下要么考慮緩存不入庫要么設計更精細的淘汰策略。面試官問“你項目里怎么處理緩存一致性的”你只需要說清楚業務場景、讀寫比例、能接受的不一致時長方案以及上線后怎么驗證和補償這個答案就是有說服力的。6. 主觀題答卷的常見坑與復習路線6.1 當年我們最容易踩的幾個坑刷主觀題和刷選擇題有一個很大的差別主觀題沒有標準答案但也沒有人幫你批改所以自己很難發現答題邏輯上的漏洞。我當時整理了一套常見坑點速查表是跟身邊好幾個一起準備秋招的同學對答案時總結出來的。常見問題典型表現如何避免只答方案不答原因說“用Redis做緩存”但不解釋為什么用Redis每個技術選型都補一句“因為……所以……”不做量級估算直接畫架構圖沒有數據支撐先算QPS、存儲量再選型忽略非功能需求只講功能邏輯不說高可用和監控加上故障預案、監控報警、降級方案鏈路題漏層從URL輸入到展示漏掉DNS或TLS按階段逐層背誦一個不漏架構方案過度設計一個短鏈接服務上了微服務加消息隊列方案匹配量級小系統用小方案被追問就懵準備過的問題能答換個角度就卡住針對每個方案準備三個追問預案這里面最虧的是“被追問就懵”。主觀題本身就是面試官考察你的窗口追問越多說明他越感興趣一旦你露出“沒想過這個問題”的狀態觀感就會打折扣。所以我在整理每道題的時候都會強迫自己追加三個反向問題比如“這個方案的瓶頸在哪”“這個環節如果掛了怎么兜底”“數據量再大10倍還能撐住嗎”。6.2 服務端校招主觀題的復習三層結構主觀題看起來千變萬化其實復習層次可以拆成三層。第一層是地基TCP/IP、HTTP協議、數據結構、操作系統、數據庫原理。這些是離散的知識點可以用思維導圖串起來每天過一遍。第二層是中間件Redis、MySQL、Kafka、Nginx不用精通源碼但至少要知道每個組件的核心數據結構和適用場景比如Redis的跳表、MySQL的B樹和事務隔離級別、Kafka的分區與消費者組、Nginx的負載均衡策略。第三層是系統設計實戰從短URL服務、秒殺系統、消息隊列、附近的人、排行榜這類經典題入手每道題都按“需求分析、量級估算、架構設計、核心細節、追問預案”五步閉環練一遍。我當時復習的時候給自己定了一條鐵律每道題必須能脫稿講滿十分鐘中間不能停頓去翻筆記。主觀題本質上是一門“講出來”的學問你腦海里想得再清楚表達不出來在面試里就等于沒有準備。對著鏡子講、錄音下來自己回聽是最笨但最有效的練法。這套題集里的六道題我后來反復看了很多遍每次看都有新的理解。尤其現在工作以后做服務端研發遇到線上接口抖動、緩存擊穿、庫存對不上賬這些問題時經常會想起當年筆試里那些看似遙遠的問題。主觀題真正考察的從來不是你記住了多少標準答案而是當你在面對一個從未見過的系統問題時有沒有一套穩定的拆解方法論。一旦建立了這套方法不管技術棧怎么更替它都不會過時。 小米服務端校招主觀題復盤：高并發與系統設計核心考點全解析
2018年秋招那會兒我把小米服務端工程師的筆試主觀題從頭到尾啃了一遍。整張卷子沒有選擇題全是需要現場組織語言、畫架構、寫方案的設計題。說實話那是我秋招遇到的第一份“考思路比考記憶多”的卷子。現在回看這套主觀題其實把服務端開發最核心的知識域都串起來了高并發設計、網絡鏈路、緩存一致性、海量數據處理。本文把這套主觀題的完整復盤寫出來每道題都拆到考察點、答題框架、追問預案三個層次適合正在準備后端或服務端校招崗位的讀者也適合剛入行、想系統建立服務端知識體系的朋友收藏。1. 主觀題全景小米服務端校招到底考什么1.1 主觀題和客觀題最大的區別在哪客觀題考“你知道不知道”主觀題考“你會不會用”。服務端工程師的主觀題尤其明顯它不會直接問你“TCP三次握手是哪三次”而是給你一個業務場景比如“設計一個支持高并發的短鏈接服務”讓你從零開始把它講清楚。這時候面試官和判卷人真正想看的不是你背了多少八股而是三個維度。第一是完整性。同樣一道短URL設計題有人只會說“用哈希生成短碼”有人能從發號器、存儲選型、緩存策略、重定向狀態碼、壓測預估講到監控報警。覆蓋的鏈路越完整說明你對服務端系統的全局認知越強。第二是取舍感。系統設計里沒有“銀彈”只有場景匹配。比如短鏈接的讀請求遠多于寫請求就適合緩存和只讀從庫秒殺場景的寫請求集中在熱點商品上就適合隊列削峰和庫存前置。能不能說清楚為什么在這個場景選這個方案是主觀題拉開分差的關鍵。第三是表達能力。方案在腦子里是一團亂麻還是能按“需求分析、量級估算、架構設計、核心細節、追問預案”的順序講出來直接決定了判卷人對你工程素養的判斷。我見過不少技術水平不差的人因為表達混亂丟了分非常可惜。1.2 當年這套題覆蓋的知識域速覽主觀題合集里一共六道題每道都對應一個獨立的知識域。我按當年的題目順序整理成了下面這個對照表方便后續逐個展開。題目考察方向核心知識點設計一個短URL服務系統設計發號器、Base62編碼、哈希沖突、301與302設計秒殺系統的服務端方案高并發限流算法、MQ削峰、庫存扣減、樂觀鎖從輸入URL到頁面展示發生了什么網絡綜合DNS、TCP、HTTP、瀏覽器渲染、緩存緩存與數據庫一致性怎么保證分布式Cache Aside、延遲雙刪、binlog補償從海量日志中統計訪問次數Top100的IP海量數據分而治之、Hash分片、堆排序服務端接口冪等性怎么設計接口設計冪等鍵、唯一索引、狀態機、重試機制這套題放到現在來看也完全不過時。這幾年各大廠的校招面經翻來翻去題目形態可能改了包裝但內核依然是這六塊。所以與其到處找題庫刷數量不如把這幾類問題的思考框架真正建立起來。我當時拿到這套題之后的第一反應是題目本身不難難的是在有限時間內把答案組織得足夠完整。這也是主觀題最磨人的地方。2. 高頻系統設計題短URL服務怎么一步步拆解2.1 拿到系統設計題先別急著寫方案短URL服務當年排在主觀題第一位也是幾乎所有服務端面試里最高頻的系統設計題目。題目一般這么描述設計一個短鏈接服務可以把長鏈接變成短鏈接用戶訪問短鏈接時能跳轉到原始長鏈接要求支撐海量訪問數據不能丟。這道題最忌諱的就是上來直接畫架構圖。正確的打開方式先拆需求。核心功能只有兩個生成短碼、跳轉還原。非功能需求有三個高可用、高性能、數據可靠。接下來做量級估算比如每天新增短鏈接1000萬條那就意味著一年存儲量在36.5億條左右MySQL只要設計好分表完全能扛住寫入訪問量的讀請求遠大于寫請求比例粗略按100比1來算峰值QPS可能到幾十萬甚至上百萬這時候必須上緩存。量級估算的意義在于它會倒逼你做出合理的技術選型。如果你沒做估算就直接說“用Redis存所有短鏈接”這是錯誤的——因為Redis內存太貴不劃算。估算完之后你會發現正確的存儲選型應該是“全量數據放MySQL熱點映射放Redis”這樣成本和性能都是可控的。2.2 短碼生成方案對比發號器為什么是首選短碼怎么生成是這道題的第一個核心決策點。市面上常見的方案有哈希、隨機數和發號器三種我當年在面試中把三種都講了最后給出了選型結論。哈希方案的思路是把原始長URL取MD5或CRC32值截取前幾位作為短碼。優點是本地計算快、不需要額外存儲依賴但缺點是哈希沖突不可控一旦兩個不同長URL算出相同短碼要么拒絕生成要么重試重算實現起來麻煩而且短碼長度也不好控制。隨機數方案是隨機生成一組字符作為短碼實現最簡單但每次生成都要查一次數據庫確認沒有撞碼生成效率低存儲的短碼索引也大。發號器方案則完全不同用數據庫自增ID或分布式ID生成器拿到一個全局遞增的ID然后把這個ID做Base62編碼。因為ID本身是唯一的編碼后的短碼天然不會沖突同時還能反向解碼還原ID連索引查詢都省了。發號器方案之所以是首選是因為它同時解決了唯一性、短碼長度和查詢效率三個問題。下面這個Python示例是我當年整理筆記時寫的展示了最核心的Base62編碼邏輯。ALPHABET 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ def base62_encode(num): if num 0: return ALPHABET[0] res [] while num 0: num, rem divmod(num, 62) res.append(ALPHABET[rem]) return .join(reversed(res)) def base62_decode(code): num 0 for ch in code: num num * 62 ALPHABET.index(ch) return num注意看編碼結果ID等于10000000時編碼出來的短碼長度只有4到5位比純隨機字符串短得多用戶體驗更好。而解碼時只需要遍歷字符串逐位計算時間復雜度是O(n)性能極高。2.3 存儲、緩存和重定向的細節別漏掉短碼方案定了之后存儲表結構基本是固定的id、short_code、original_url、created_at其中short_code加唯一索引。這里有個細節如果直接用唯一的short_code作為主鍵那在數據量大之后分庫分表的鍵選擇會更方便可以把short_code作為分片鍵這樣同一個短碼的查詢永遠只落在同一個分片上。查詢跳轉的流程是典型的Cache Aside模式先查Redis命中直接返回長URL沒有命中就回源MySQL查詢查到后回填Redis并返回Redis里查不到且數據庫也沒有就返回404。回填的時候記得設置過期時間比如一到兩天避免冷數據長期占用內存。重定向狀態碼選301還是302是這道題里最經典的追問點。301是永久重定向瀏覽器會緩存跳轉結果第二次訪問同一個短鏈接時瀏覽器干脆不發請求直接跳到長URL服務端壓力小但拿不到點擊量數據。302是臨時重定向每次訪問都會請求服務端方便統計點擊數據但會給服務端帶來更多請求量。業務方如果對點擊數據敏感比如營銷活動想看轉化率就選302如果完全不在意統計只求省資源301也可以。面試里建議說“大多數業務場景選302因為統計優先”。2.4 追問環節的高頻深挖點面試官不會滿足于你講完主體方案大概率會追問三個方向。第一個方向是并發安全發號器的ID并發重復怎么辦答案是數據庫自增ID天然保證并發唯一如果擔心數據庫單點瓶頸可以用號段模式一次性從數據庫取一批ID到內存比如每次取1萬個發完再去取數據庫壓力直接降幾個數量級。第二個方向是安全問題短碼只有幾個字符暴力枚舉怎么辦可以給短碼加隨機位打散規律性同時對同一個IP的訪問頻率做限流防止惡意遍歷。第三個方向是雪崩問題緩存大面積失效怎么辦Redis的key要設置合理過期時間加隨機偏移數據庫層要有降級預案比如限制只允許一部分節點回源其他節點直接返回提示頁。這道題只要把“需求拆解、量級估算、發號器、Cache Aside、301/302、追問預案”這六步完整走一遍基本就能拿到基準以上的分數。它的套路其實就是所有系統設計題的通用套路。3. 高并發場景題秒殺系統的服務端方案怎么答3.1 秒殺的本質不是賣貨是流量管控秒殺是服務端面試里另一道經久不衰的場景題。題目通常這樣出某個商品庫存1萬件開放搶購后瞬間涌入百萬級請求請設計服務端方案要求不能超賣、不能崩潰、用戶體驗盡量平滑。拿到這種題第一個要扭轉的思維是不要試圖讓所有請求都成功。秒殺系統的本質是一次大規模的流量管控1萬件庫存對應的有效請求只有1萬個剩下的99萬個請求注定要失敗系統要做的不是讓它們全部進入業務流程而是讓絕大部分請求在入口處就被攔截掉。這個思維可以泛化到所有服務端高并發場景昂貴資源數據庫、磁盤IO、下游第三方接口永遠不應該直接暴露在全部流量之下。我當時把這套思路總結成三層攔截模型網關層擋掉非法請求和超出閾值的流量應用層限流和排隊數據層只用真正有資格的請求去觸碰庫存。很多方案翻車往往是因為直接把用戶請求打到了數據層導致數據庫連接池被瞬間打滿整個服務連帶宕機。3.2 服務端限流算法選型從固定窗口到令牌桶限流是秒殺系統的地基也是服務端接口保護的基本功。面試中你至少要能講清楚四種限流算法的適用場景和缺陷。固定窗口計數器是最簡單的方式每秒一個窗口窗口內計數超過閾值直接拒絕。問題在于臨界突變0到1秒的窗口和1到2秒的窗口各自允許100個請求那在臨界點前后可能瞬間放過200個請求流量不夠平滑。滑動窗口在固定窗口的基礎上把窗口細分成多個小格子滾動統計能有效消除臨界突變但實現上要維護時間輪占用更多內存。漏桶算法像一個漏斗請求先進入桶里以固定速率流出不管上游流量多大下游拿到的始終是勻速的。它適合保護下游系統但代價是請求延遲被拉高。令牌桶算法則是以固定速率往桶里放令牌請求來的時候必須拿到令牌才能通過桶里最多攢滿一定數量的令牌所以它允許一定程度的突發流量性能好也是實際工程里用得最多的方案。下面是一個基于Redis計數器做簡單限流的偽代碼生產環境可以換成Lua腳本保證原子性。// 基于Redis INCR的固定窗口限流偽代碼 String key rate_limit: System.currentTimeMillis() / 1000; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1) { redisTemplate.expire(key, 2, TimeUnit.SECONDS); } if (count ! null count MAX_QPS_PER_WORKER) { throw new BizException(訪問過于頻繁請稍后再試); }面試中可以這樣總結選型并發量小、實現簡單選固定窗口下游保護優先選漏桶既要扛突發流量又要穩定輸出選令牌桶。秒殺場景下接口層用令牌桶下單入口用隊列削峰兩者配合。3.3 庫存扣減怎么避免超賣限流只是擋掉了大部分流量真正處理剩余的“有效請求”時最怕的是超賣。庫存扣減的經典方案是數據庫行鎖SQL長這樣UPDATE stock SET count count - 1 WHERE product_id ? AND count 0;關鍵在于count 0這個條件在并發事務中MySQL的行鎖會讓同一行記錄的操作串行化只有一個事務能把count減到0其他事務因為條件不滿足更新行數為0不會真正扣減所以天然能防超賣。但它的缺點是大量請求同時競爭同一行的鎖數據庫壓力非常大吞吐量受限。另一種思路是樂觀鎖。給庫存表加version字段更新時帶上版本號版本號變了就說明被別人改過重試或返回失敗。秒殺場景下庫存是熱點數據樂觀鎖重試次數會非常多體驗反而不好所以更推薦的做法是Redis預扣減。所謂預扣減就是先把庫存同步到Redis用DECR命令原子減一減完大于等于0才算成功然后立刻返回用戶“搶購成功”。真正的數據庫庫存扣減通過MQ異步消息來完成而不是讓用戶請求同步等待。Redis的單線程模型天然串行化性能遠高于數據庫行鎖能抗住幾十萬的扣減QPS。這里要注意的是Redis扣減成功但異步消息投遞失敗會造成Redis和數據庫庫存不一致所以必須引入對賬任務定期比對兩邊庫存發現差異就補償。3.4 秒殺方案的通用回答模板這道題回答時我建議按下面這個順序來。第一需求分析明確庫存量、預估峰值QPS、超賣容忍度。第二前端攔截按鈕置灰、動態令牌先把腳本刷量擋掉。第三網關層限流按用戶維度、IP維度雙重限制。第四應用層排隊把真正進入下單流程的請求壓進MQ用隊列長度控制數據庫壓力。第五庫存扣減Redis預扣減加數據庫最終扣減。第六兜底方案對賬補償、人工介入。這套模板不只是為秒殺準備的凡是涉及高并發寫入的系統都可以參考。4. 網絡綜合題從輸入URL到頁面展示的完整鏈路4.1 全鏈路七層梳理這道題幾乎是服務端面試的必考題因為它能一次性考察網絡基礎、操作系統、Web服務、瀏覽器原理多個領域。題目描述很簡短用戶在瀏覽器輸入一個URL按下回車到頁面完整展示中間發生了什么。完整的回答鏈路我習慣分成八個階段。第一階段是URL解析瀏覽器提取協議、域名、端口、路徑和查詢參數。第二階段是緩存查找瀏覽器緩存、系統緩存、路由器緩存甚至DNS服務器緩存都查一遍有沒有對應的IP。第三階段是DNS解析把域名解析成IP這個過程中會涉及本地DNS服務器、根DNS服務器、頂級域名服務器、權威域名服務器的遞歸或迭代查詢。第四階段是TCP連接建立三次握手。第五階段是發送HTTP請求如果用了HTTPS還要先經歷TLS握手協商密鑰。第六階段是服務端處理請求經過負載均衡、應用邏輯、數據庫查詢后返回響應。第七階段是瀏覽器解析HTML、CSS、JavaScript構建DOM樹和渲染樹。第八階段是連接關閉或者保持長連接復用。這道題能拿高分的要點不在于把八階段背下來而在于每個階段都能講出幾個“別人不常提的細節”。4.2 每個階段容易忽略的細節DNS階段容易被忽略的點是緩存和TTL。DNS查詢結果并不是每次都全鏈路遞歸每一層都有緩存緩存時間由TTL控制所以一次域名解析可能只要幾毫秒也可能因為緩存過期需要重新走完整遞歸鏈路而耗時幾百毫秒。面試官如果問“為什么首次訪問慢、后續訪問快”答案就在這里。TCP階段最經典的問題是為什么三次握手而不是兩次。答案很簡單三次握手能讓雙方都確認自己的發送能力和接收能力是正常的。第一次握手客戶端確認自己發送能力正常、服務端接收正常第二次握手服務端確認自己發送能力正常、客戶端接收正常第三次握手客戶端再確認一次雙方收發都正常順便告訴服務端可以開始發數據了。兩次握手的話服務端無法確認客戶端的接收能力。HTTP階段值得展開的是協議演進。HTTP/1.1引入了Keep-Alive長連接和管線化但管線化存在隊頭阻塞問題前一個請求不結束后一個響應就得等著。HTTP/2通過多路復用解決了HTTP層的隊頭阻塞但TCP層的隊頭阻塞依然存在。HTTP/3干脆改用基于UDP的QUIC協議徹底繞開了TCP層的隊頭阻塞問題。這一段如果能在面試中主動講出來面試官對你的網絡功底會明顯加分。還有HTTPS。如果URL是https開頭那在TCP連接建立之后還要額外做TLS握手客戶端發送支持的加密套件列表服務端返回證書客戶端驗證證書鏈并生成會話密鑰雙方協商加密方案。這個環節最容易答漏但它恰恰是現代服務端最基礎的安全能力。4.3 面試官的挖坑方式長什么樣這類題目答完主體鏈路之后面試官一般會沿著細節繼續追問。比如輸入一個不存在的域名會怎樣答案是DNS解析失敗瀏覽器顯示“無法訪問該網站”服務端側根本收不到任何請求所以排障第一步應該先確認域名解析記錄有沒有配錯。再比如如果目標服務器的端口根本沒有進程監聽客戶端會收到什么答案是RST包TCP連接直接被重置而不是正常的四次揮手FIN包。這個問題的意義在于區分“端口不可達”和“連接正常關閉”是兩種完全不同的狀態。又比如為什么頁面里有大量圖片資源時HTTP/1.1需要建立多個連接因為HTTP/1.1的Keep-Alive雖然是長連接但同一個連接同一時刻只能處理一個請求瀏覽器為了并行加載資源只能開多個TCP連接而HTTP/2的多路復用允許在一個連接上同時并發多個請求。這些問題每個都是知識點不需要猜題只要把鏈路理解透了怎么問都能接住。5. 緩存與數據庫一致性判斷依據和工程取舍5.1 緩存三大問題穿透、擊穿、雪崩服務端面試聊緩存繞不開這三個經典問題。穿透是指用戶查詢一個根本不存在的數據緩存里沒有數據庫里也沒有請求每次都穿透到數據庫如果被惡意腳本大量發起數據庫響應就會被打爆。解決辦法是緩存空值給不存在的key也寫一個短暫的空緩存或者用布隆過濾器在請求到達數據庫之前判斷key是否存在不存在直接返回。擊穿是指某個熱點key在過期的一瞬間大量請求同時發現緩存沒有數據一起打到數據庫上。解決辦法是熱點key不設置過期時間或者把過期時間拉長同時用后臺任務異步更新緩存保證舊數據在過期后依然可以被請求命中而不是讓請求穿透。雪崩是指大量key在同一時間段內集中過期導致數據庫瞬間承受大量請求。解決辦法很簡單每個key的過期時間加一個隨機偏移量比如在五天到七天之間隨機讓過期時間自然錯峰。這三大問題在答題時很多人會混淆我的記憶方法是穿透是不存在的key擊穿是單個熱點key過期雪崩是批量key過期。三個問題對應三個解決思路別混。5.2 Cache Aside模式與延遲雙刪的細節緩存讀寫策略里Cache Aside是最主流的一種也是服務端日常開發中最常被問到的一種。讀流程是先查緩存命中直接返回沒命中就查數據庫把結果回填緩存再返回。寫流程是先更新數據庫再刪除緩存。為什么是刪除而不是更新緩存原因有兩層。第一層更新緩存成本高于刪除緩存。更新緩存要重新序列化對象、寫Redis而且可能寫入一個之后永遠不會被讀到的冷數據刪除只是O(1)操作。第二層并發環境下更新緩存容易產生舊值覆蓋新值的問題。兩個請求同時寫同一個數據后到的請求先寫了數據庫前到的請求后寫了緩存緩存里存的實際上是舊值這比刪除緩存引發的不一致更麻煩。那么先刪緩存再更新數據庫行不行也不行。假設請求A刪除緩存后還沒來得及更新數據庫請求B來讀緩存發現沒數據回源數據庫讀到了舊值并回填緩存這時請求A才更新數據庫緩存里就永遠留下了舊值。所以標準做法是先更庫再刪緩存。后來又有人提出延遲雙刪先刪緩存、更新數據庫、等幾百毫秒再刪一次緩存把中間窗口期被重新填進去的舊值清掉。延遲雙刪能降低不一致概率但在極端情況下如果第二次刪除失敗該不一致還是不一致所以更可靠的方案是訂閱數據庫binlog解析出變更事件后刪除對應緩存刪除失敗就重試。這個方案復雜度高但工程上最可靠。5.3 一致性要求的業務分級和選型邏輯面試中說到緩存一致性不要只背方案要能讓面試官看到你的取舍判斷。一致性要求是分級的。普通業務數據比如用戶昵稱、文章閱讀數能接受秒級別的暫時不一致用Cache Aside就夠了。強一致要求的數據比如支付狀態、訂單狀態緩存只讀不寫或者直接不走緩存所有讀寫都落數據庫。中間態的數據比如購物車內容允許短時間弱一致可以用延遲雙刪或者binlog補償。還有一個容易被忽略的維度是讀寫比例。同一個數據如果讀多寫少緩存命中率很高先更庫再刪緩存的代價就很小如果寫非常頻繁那每次寫都要刪一次緩存下一次讀又必然miss回源緩存反而成了負擔。這種情況下要么考慮緩存不入庫要么設計更精細的淘汰策略。面試官問“你項目里怎么處理緩存一致性的”你只需要說清楚業務場景、讀寫比例、能接受的不一致時長方案以及上線后怎么驗證和補償這個答案就是有說服力的。6. 主觀題答卷的常見坑與復習路線6.1 當年我們最容易踩的幾個坑刷主觀題和刷選擇題有一個很大的差別主觀題沒有標準答案但也沒有人幫你批改所以自己很難發現答題邏輯上的漏洞。我當時整理了一套常見坑點速查表是跟身邊好幾個一起準備秋招的同學對答案時總結出來的。常見問題典型表現如何避免只答方案不答原因說“用Redis做緩存”但不解釋為什么用Redis每個技術選型都補一句“因為……所以……”不做量級估算直接畫架構圖沒有數據支撐先算QPS、存儲量再選型忽略非功能需求只講功能邏輯不說高可用和監控加上故障預案、監控報警、降級方案鏈路題漏層從URL輸入到展示漏掉DNS或TLS按階段逐層背誦一個不漏架構方案過度設計一個短鏈接服務上了微服務加消息隊列方案匹配量級小系統用小方案被追問就懵準備過的問題能答換個角度就卡住針對每個方案準備三個追問預案這里面最虧的是“被追問就懵”。主觀題本身就是面試官考察你的窗口追問越多說明他越感興趣一旦你露出“沒想過這個問題”的狀態觀感就會打折扣。所以我在整理每道題的時候都會強迫自己追加三個反向問題比如“這個方案的瓶頸在哪”“這個環節如果掛了怎么兜底”“數據量再大10倍還能撐住嗎”。6.2 服務端校招主觀題的復習三層結構主觀題看起來千變萬化其實復習層次可以拆成三層。第一層是地基TCP/IP、HTTP協議、數據結構、操作系統、數據庫原理。這些是離散的知識點可以用思維導圖串起來每天過一遍。第二層是中間件Redis、MySQL、Kafka、Nginx不用精通源碼但至少要知道每個組件的核心數據結構和適用場景比如Redis的跳表、MySQL的B樹和事務隔離級別、Kafka的分區與消費者組、Nginx的負載均衡策略。第三層是系統設計實戰從短URL服務、秒殺系統、消息隊列、附近的人、排行榜這類經典題入手每道題都按“需求分析、量級估算、架構設計、核心細節、追問預案”五步閉環練一遍。我當時復習的時候給自己定了一條鐵律每道題必須能脫稿講滿十分鐘中間不能停頓去翻筆記。主觀題本質上是一門“講出來”的學問你腦海里想得再清楚表達不出來在面試里就等于沒有準備。對著鏡子講、錄音下來自己回聽是最笨但最有效的練法。這套題集里的六道題我后來反復看了很多遍每次看都有新的理解。尤其現在工作以后做服務端研發遇到線上接口抖動、緩存擊穿、庫存對不上賬這些問題時經常會想起當年筆試里那些看似遙遠的問題。主觀題真正考察的從來不是你記住了多少標準答案而是當你在面對一個從未見過的系統問題時有沒有一套穩定的拆解方法論。一旦建立了這套方法不管技術棧怎么更替它都不會過時。