七牛云這家公司搞云存儲和 CDN 的同行應該都不陌生。2018 年那會兒國內云計算格局正在快速成型七牛云作為對象存儲和內容分發領域的頭部玩家之一它的校招筆試題向來以基礎扎實 工程思維著稱。我當年幫實驗室的學弟整理過這套卷卷三后來自己也做了幾年的存儲后端如今再回頭看發現里面很多考點到現在依然是面試的核心篩選項。這篇文章就來把這份卷子掰開揉碎從考點分布、典型題目、答題思路到避坑經驗一次性講清楚。先給個結論這份卷子不是那種純刷題就能過的類型它真正篩選的是基礎過硬 能落地干活的人。如果你是準備云廠商、存儲方向、CDN 方向校招的應屆生這篇文章值得你靜下心看完。1. 筆試全貌拆解先看七牛云在考什么1.1 七牛云的技術底色決定出題方向理解一份筆試題先理解這家公司靠什么吃飯。七牛云的核心業務是對象存儲、CDN 加速、數據處理管道也就是幫企業把海量文件存起來、發出去、處理掉。這就決定了它對候選人的技術偏好第一網絡基礎必須硬。CDN 本質上是把內容推到離用戶最近的地方涉及 DNS 解析、HTTP 協議、TCP/IP、緩存策略、回源邏輯這些全都跑不掉。第二存儲和分布式系統是重頭。對象存儲背后是分布式集群、數據冗余、一致性協議哪怕只是做個簡單的上傳下載也要理解底層原理。第三Linux 和工程能力是底線。云廠商的研發日常就是跟 Linux 服務器、shell 腳本、性能排查打交道筆試里出現系統命令、進程模型非常正常。1.2 卷三的整體結構與考察范圍從各方回憶和同類試卷對照來看2018 七牛云校招筆試題卷三大體分為四個模塊客觀題包括單選題和多選題覆蓋數據結構、操作系統、計算機網絡、數據庫基礎大概 20 到 30 道。算法編程題兩道左右純手寫代碼考察基礎算法能力和邊界處理。簡答/設計題一到兩道通常給一個實際場景比如文件上傳慢、緩存命中率低讓你分析原因設計方案。附加題部分崗位Linux 命令實戰、shell 腳本編寫或系統調優思路。四部分占比并不平均。客觀題考察廣度編程題考察硬功夫設計題決定上限。很多入選者反饋客觀題大家差距不大真正拉開分數的是編程題的代碼質量和設計題的思路完整度。1.3 評分邏輯不是對答案而是看思維這一點我體會很深。筆試不是只看最終答案對不對尤其編程題和設計題閱卷人更關注你的思考路徑。代碼是不是簡潔清晰有沒有考慮異常分支設計題里有沒有主動考慮一致性、可用性、成本這些都是隱性評分點。也就是說哪怕你的方案不是最優解只要邏輯自洽、考慮周全也能拿到不錯的分數。2. 核心考點逐項拆解四個維度一個都不能少2.1 數據結構與算法不刷題真的會掛在第一關七牛云的算法題不算變態但非常講究穩。常考的類型包括鏈表操作、二叉樹遍歷、字符串處理、動態規劃基礎題很少出那種偏怪難的 ACM 題。但它的特點是題目看似簡單邊界條件多到讓人崩潰。舉個典型例子反轉鏈表大家都寫過但它可能升級成每 K 個節點一組反轉。這道題考察的不只是反轉邏輯還有對鏈表長度、剩余節點不足 K 個、頭節點變更等情況的處理。很多人代碼能跑通基本用例一到空鏈表、單節點鏈表、K 等于 1 這些邊界就露餡。我的建議是復習時不要只刷我會做的題要把每道題的所有邊界條件列出來逐一驗證。劍指 Offer 和 LeetCode 熱題 100 覆蓋足夠關鍵是每道題都做到 bug free而不是看一眼思路就往下走。2.2 計算機網絡CDN 工程師的命根子網絡部分在卷三里占的比重非常高這也符合七牛云的業務特點。重點集中在HTTP 協議請求方法、狀態碼、常見 HeaderCache-Control、ETag、Last-Modified、HTTP/1.1 與 HTTP/2 的區別。TCP 相關三次握手四次揮手、擁塞控制、TIME_WAIT 狀態。DNS 解析流程從瀏覽器輸入域名到拿到 IP中間經歷了什么。緩存相關強緩存與協商緩存的區別什么是緩存命中什么是回源。這里有一道經常出現的經典題用戶在瀏覽器訪問一張圖片第一次很慢第二次很快解釋一下為什么。這道題表面考 HTTP 緩存實際是想看你有沒有完整的鏈路意識瀏覽器緩存、CDN 邊緣節點緩存、源站存儲層層遞進。回答時如果能從瀏覽器緩存聊到 CDN 緩存再到回源策略就基本拿滿分數。2.3 操作系統與 Linux 基礎工程落地的底盤云廠商的研發日常離不開 Linux所以操作系統和 Linux 命令也是必考模塊。常見考點包括進程與線程的區別、進程間通信方式、同步與互斥、死鎖產生的四個條件、虛擬內存與分頁。Linux 部分則會考一些非常實操的內容比如如何查看系統負載top/uptime、如何排查端口占用netstat/lsof、如何查看磁盤空間和 inode 使用情況df -i、如何用 awk/sed 處理文本。這些題目不靠背靠真用過。我在實際工作中招聘面試時發現很多簡歷寫著熟悉 Linux結果連 awk 的常見用法都說不出來。筆試里這類題存在的意義就是過濾掉那些只會在簡歷上寫關鍵詞的人。2.4 分布式與存儲基礎云廠商的看家本領對七牛云這種公司來說分布式存儲相關的題目是拉開差距的地方。考察點通常包括數據冗余與副本機制多副本和糾刪碼的區別各自的優缺點。一致性模型強一致性和最終一致性的區別分布式系統為什么很難做到強一致。負載均衡算法輪詢、隨機、最少連接數、一致性哈希各自適用的場景。對象存儲的基本概念桶Bucket、對象Object、鍵Key的組織方式。一致性哈希這道題幾乎年年出現。因為它考察的不只是算法本身而是你有沒有理解分布式系統里節點變化時如何盡量減少數據遷移這個核心痛點。回答時建議畫出哈希環講清楚虛擬節點的作用然后聯系實際為什么許多分布式緩存和存儲系統都用它而不用簡單的取模。3. 典型題目深度解析與答題示范3.1 進階鏈表操作每 K 個節點一組反轉這是卷三里很有代表性的一道手寫代碼題。原題大意是給定一個鏈表和一個整數 K每 K 個節點一組進行反轉如果剩余節點不足 K 個則保持原有順序最后返回新鏈表的頭節點。先講思路這道題用遞歸寫最清晰。定義一個函數 reverseKGroup(head, k)先從頭走 k 步若能走完翻轉這一段然后遞歸處理剩下的鏈表再把翻轉后的尾部接到遞歸結果上。關鍵點是指針走 k 步時要注意 null 終止。翻轉 k 個節點時可以復用標準的鏈表翻轉模板但要記錄這段的頭尾。遞歸的返回值需要正確接到上一段的尾部。參考代碼Go 語言版本我日常工作用 Go 多type ListNode struct { Val int Next *ListNode } func reverseKGroup(head *ListNode, k int) *ListNode { if head nil { return nil } // 先檢查剩余節點是否夠 k 個 cur : head count : 0 for cur ! nil count k { cur cur.Next count } if count k { return head } // 翻轉前 k 個節點 var prev *ListNode cur head for i : 0; i k; i { next : cur.Next cur.Next prev prev cur cur next } // 遞歸處理剩余鏈表接到當前段尾部 head.Next reverseKGroup(cur, k) return prev }代碼里最容易錯的不是翻轉而是最后一行 head.Next 的賦值。head 此時是翻轉后的尾節點必須把它接到剩余部分遞歸的結果上否則鏈表就斷了。這里能寫對說明你真的理解了指針指向的變換而不是背模板。3.2 網絡綜合題從一次圖片訪問引申出的完整鏈路再來一道網絡綜合題用戶訪問 http://img.example.com/a.jpg第一次打開很慢第二次明顯變快請分析整個過程并說明第一次慢可能的原因。這道題的答題思路要分層第一層DNS 解析。首次訪問要解析 img.example.com 的域名如果本地沒有緩存需要走完整的 DNS 迭代查詢這一步可能耗時幾十到幾百毫秒。第二層TCP 連接。建立 TCP 連接需要三次握手如果是 HTTPS 還要加 TLS 握手RTT 高的情況下會更明顯。第三層CDN 調度。如果這個域名接了 CDNDNS 解析會返回 CDN 邊緣節點的 IP用戶從邊緣節點拿數據。首次訪問時如果邊緣節點沒有緩存就要回源到七牛云的對象存儲拉取圖片再緩存到邊緣節點。這就是首次慢、二次快的核心原因。第四層HTTP 緩存。第二次訪問時瀏覽器本地可能命中了強緩存Cache-Control: max-age或者通過 ETag / Last-Modified 發了協商緩存請求304 響應直接復用本地副本。答題時把這些鏈路講完整同時點出回源這個關鍵動作就能體現出你對 CDN 業務的理解深度。3.3 場景設計題設計一個支持秒傳的文件上傳接口設計題是卷三的壓軸常見場景是為對象存儲設計一個文件上傳接口要求支持秒傳。秒傳的原理其實就是文件指紋去重客戶端先計算文件的哈希值通常用 SHA-1 或 MD5配合文件大小把哈希值傳給服務端。服務端在元數據里查一下如果已經存在相同哈希的文件就不需要真正上傳數據了直接把新引用的元數據指向已有對象即可。答題時要注意幾個點哈希碰撞概率雖然低但生產環境要二次確認通常加一個文件大小的比對甚至抽樣校驗。上傳流程要拆分初始化上傳申請 uploadId、分片上傳可選、完成上傳合并分片并觸發去重檢查、回調通知。并發去重時會遇到競態條件兩個客戶端同時上傳同一個哈希的文件需要用分布式鎖或者讓去重檢查在存儲層原子完成避免產生兩份相同數據。這道題考察的不是你會不會調 SDK而是你有沒有架構思維能不能把一個簡單功能拆成可落地的多模塊流程。4. 高頻扣分點復盤這些坑我見得太多了4.1 邊界條件就是送命題算法題寫得好不好邊界條件占一半。很多候選人拿到題就開始寫循環寫完 main 用例一跑誒對了就交卷。結果邊界用例一測崩了。我整理幾個高頻邊界場景你們寫代碼時對照檢查對鏈表操作先確認 head 是否為 nil鏈表長度是否只有 1。對數組操作確認數組長度為 0 時你的代碼不會越界訪問。對二分查找left 和 right 的初始化邊界直接決定死循環與否建議用左閉右開區間統一邏輯。對字符串處理考慮空串、全空格、大小寫混合的輸入。筆試環境里的測試用例往往不全如果你自己能主動構造邊界用例去驗證就已經超過了 80% 的候選人。4.2 分布式題瞎扯一致性協議我在審卷時經常看到一種回答一提到分布式張口就是 ZAB、Raft、Paxos好像誰說的協議多誰就贏了。但問到你的系統到底需要強一致還是最終一致時很多人反而說不清楚。答題最重要的思維是一致性是一個 spectrum不是只有 0 和 1。你要做的是根據業務場景選一個合適的級別。比如對象存儲的元數據操作創建桶、刪除對象需要強一致否則會出現刪了還能讀到的詭異問題而文件內容分發到 CDN 邊緣節點則天然是最終一致的因為邊緣緩存本來就有 TTL。筆試時遇到這類題先定位場景再談方案。先用一句話說清楚業務對一致性的需求再去描述協議原理分數就穩穩拿到手。反過來上來就背協議細節只會在不相關的邊緣被扣分。4.3 時間分配失衡導致編程題直接放空每年都有人客觀題摳太久最后編程題只寫了個函數簽名就交了。卷三的量不輕客觀題里偶爾會有計算題比如 IP 地址劃分、內存頁面置換次數非常耗時。我的建議是拿到卷子先花兩分鐘掃一遍全卷把編程題和設計題的題目讀完然后先做編程題再做設計題最后回頭啃客觀題。原因很簡單編程題和設計題分值重、區分度高而且就算拿不穩也有思路分。客觀題是踩點分你對就是對錯就是錯是零和博弈。先保證大題有產出再回頭拿小題的分是性價比最高的策略。5. 面向今天校招的備考建議5.1 復習路徑怎么排更高效如果你現在正在準備云廠商的校招筆試我的建議是分三階段準備。第一階段打基礎用兩周時間把數據結構和計算機網絡過一遍。數據結構重點放在數組、鏈表、棧、隊列、樹、哈希表、排序和二分查找。計算機網絡重點放在 HTTP、TCP、DNS、緩存。推薦《圖解HTTP》和《計算機網絡自頂向下方法》配合刷題。第二階段刷題用三到四周時間刷 LeetCode 熱題 100 和劍指 Offer。重點練習鏈表、二叉樹、動態規劃、棧與隊列這四類。每道題都要求自己先寫測試用例再寫代碼最后對著邊界復測。要讓自己養成閉環習慣題目讀懂、思路寫出、代碼寫完、邊界驗證、復雜度分析五步一個都不能少。第三階段模擬實戰找兩套云廠商的歷年校招筆試真題網上資料很多卡著時間完整做一遍。做的時候嚴格按照先編程題后客觀題的策略模擬真實考場節奏。做完后不要只看對錯要復盤每道題花了多長時間卡在哪里是知識點遺漏還是手速問題。5.2 面試官真正在意的三個品質從筆試到面試我自己的體感是校招越來越不看你會多少而看你能不能上手干活。這背后是三個品質第一個品質是工程嗅覺。同樣是寫一個文件上傳接口有人只寫三個接口完事有人會主動考慮分片斷點續傳、并發去重、回調重試機制。這種差距不是刷題能補的需要平時多讀開源項目代碼多看云廠商的文檔和最佳實踐。第二個品質是對故障的敏感度。一個合格的云廠商工程師聽到緩存命中率低的第一反應應該是去查哪些 key 的訪問量高但命中低而不是上來就要改架構。筆試設計題里那些給一個故障現象讓分析原因的問題本質就在考察這種敏感度。第三個品質是表達的結構化。面試和筆試的簡答題里我最欣賞的表達方式是先給結論再列原因最后說方案。比如問為什么數據庫查詢變慢了回答我先懷疑是索引失效因為 SQL 里對索引列做了函數運算驗證方式是執行 EXPLAIN 看執行計劃解決方案是改寫 SQL 為范圍查詢——這樣答題閱卷人幾乎不用費勁就能抓到你的思路。5.3 多看存儲與 CDN 的經典資料如果你的目標明確是七牛云這類存儲/CDN 方向的公司有幾份資料值得反復精讀。第一份是《大規模分布式存儲系統》原理解析部分重點看數據分布、副本一致性。第二份是七牛云官方文檔里關于對象存儲、數據處理管道的內容尤其是上傳流程和錯誤碼定義能幫你建立對真實產品的感知。第三份是 CDN 技術的科普文章重點理解邊緣節點、回源、緩存命中和刷新預熱這套機制。說實話2018 年的卷子放在今天看題型和考點并沒有本質變化。云計算行業的技術框架已經趨于穩定校招更看重的是你在這個框架里的基礎扎實度和解決問題的思路完整度。這也是為什么這份舊題目依然有參考價值。6. 常見問題速查考前翻一遍能救急我把筆試中最高頻的幾個知識點整理成一張速查表考前快速過一遍非常管用。考點一句話核心高頻陷阱強緩存 vs 協商緩存強緩存不發請求協商緩存發條件請求分不清 Cache-Control 和 ETag 的觸發順序TCP 三次握手SYN, SYNACK, ACK 的時序不知道為什么不是兩次握手進程 vs 線程進程是資源分配單位線程是調度單位把調度和資源分配混為一談死鎖四條件互斥、持有并等待、不可剝奪、循環等待漏答一個條件一致性哈希節點變化時最小化數據遷移忘記聊虛擬節點多副本 vs 糾刪碼多副本讀性能好糾刪碼存儲成本低只談復制因子 3 不談糾刪碼對象存儲概念Bucket 是命名空間Object 是數據實體混淆防篡改和加密秒傳原理哈希去重不重復傳輸內容忘記考慮并發去重的競態這個表的價值在于考前只需要掃一遍就能把最基礎、最容易丟分的點全部拉起來。但特別注意表格只是索引真正答題時一定要展開說明不能只寫幾個關鍵詞。拿強緩存 vs 協商緩存來說完整回答應該是瀏覽器第一次拿到響應時如果響應頭帶了 Cache-Control: max-age3600那么在 3600 秒內的后續請求直接使用本地緩存不發網絡請求這就是強緩存等到緩存過期后瀏覽器帶上 If-None-Match對應 ETag重新發請求服務器返回 304 表示資源未修改瀏覽器繼續使用本地緩存這是協商緩存。只有把鏈路講完整閱卷人才能確認你真的懂而不是背了結論。我個人在帶新人的過程中發現很多筆試能過的人不是因為他們刷了更多的題而是因為他們對每個知識點都能講出三層是什么、為什么、怎么用。你翻一翻手上的筆試題凡是那些讓你糾結的題目試著用這個三層框架去套一套往往很快就能找到自己的盲區。最后再分享一個小技巧拿到筆試題后如果時間允許先在草稿紙上把每個大題的答題框架列出來再動手寫詳細內容。這個習慣幫我避免了很多次寫到一半發現跑題的尷尬。對于七牛云這套卷子來說設計題尤其適合先列框架再填充內容因為它的評分點分散在多個維度有框架才不會漏點。