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