1. 先從卷子看網(wǎng)易的考核邏輯1.1 這份卷子考了什么又為什么值得翻出來2018年網(wǎng)易校招云計算存儲開發(fā)工程師的筆試卷放到今天依然很有參考價值。原因很簡單存儲方向的核心知識點五年八年都不太會大變。當(dāng)年考的是分布式系統(tǒng)、存儲引擎、對象存儲、KV、緩存、IO模型這些東西今天面試還在問這些換個問法而已。我當(dāng)年刷過這份題也帶著不少學(xué)弟學(xué)妹復(fù)盤過。整張卷子給我最深的印象是它不考死記硬背而是在考你“遇到存儲問題時的第一反應(yīng)”。比如給你一個寫入延遲偏高的場景你會先想到WAL落盤、還是先想到鎖競爭、還是先想到網(wǎng)絡(luò)分區(qū)這種題沒有標(biāo)準(zhǔn)答案但你能寫到哪一層基本就代表了你的水平在哪個段位。從招聘崗位來看網(wǎng)易當(dāng)年的存儲團隊主要維護對象存儲、分布式塊存儲、以及各類KV組件。所以卷子覆蓋了幾個固定模塊數(shù)據(jù)結(jié)構(gòu)與算法、操作系統(tǒng)與網(wǎng)絡(luò)、分布式系統(tǒng)理論、存儲引擎原理、以及最后的場景設(shè)計題。每個模塊都不算特別深但組合起來覆蓋面很廣想拿高分必須“既懂理論又能落地”。1.2 為什么說這套考核思路對現(xiàn)在求職仍有參考價值我接觸到不少準(zhǔn)備云計算存儲方向校招的同學(xué)很容易陷入兩個極端要么只知道背面試題要么只埋頭寫業(yè)務(wù)代碼兩者都很難應(yīng)對這類筆試卷。這份卷子的出題思路本質(zhì)上是在篩選“具備系統(tǒng)全局觀”的候選人。存儲系統(tǒng)是典型的下層基礎(chǔ)設(shè)施任何一個環(huán)節(jié)出問題都會向上傳導(dǎo)所以它要求開發(fā)工程師不僅要會調(diào)API還要理解IO路徑上每一層發(fā)生的事情。這和今天“云計算運維”、“AI應(yīng)用開發(fā)工程師”的崗位也很像——技術(shù)棧可以換但底層思維是共通的。所以如果你正準(zhǔn)備存儲方向或云計算方向的校招這份2018年的卷子不是用來“刷”的而是用來“拆”的。把每一道題背后對應(yīng)的知識域列出來你就得到了一個非常清晰的復(fù)習(xí)大綱。接下來我就按這份卷子的模塊結(jié)構(gòu)把核心知識點和答題思路逐一展開。2. 數(shù)據(jù)結(jié)構(gòu)與存儲模型先過筆試?yán)锏挠查T檻2.1 哈希索引與LSM Tree選擇背后的性能賬本筆試卷里有一類高頻題給你幾種數(shù)據(jù)結(jié)構(gòu)問它們在存儲場景下的適用性。哈希表、跳表、B樹、LSM Tree幾乎是必考組合。很多人能說出各自的定義但講不清“為什么存儲系統(tǒng)要這樣選”這才是丟分點。哈希索引的優(yōu)勢是單點查詢O(1)但這個O(1)的前提是數(shù)據(jù)全在內(nèi)存或者哈希桶的沖突可控。一旦數(shù)據(jù)量大到需要落盤哈希索引的隨機IO會非常難受。傳統(tǒng)關(guān)系型數(shù)據(jù)庫用B樹是為了讓范圍查詢和等值查詢都能走有序結(jié)構(gòu)但B樹的寫入會產(chǎn)生大量隨機寫頁SSD上還行機械盤上就是災(zāi)難。LSM Tree的思路是“順序?qū)憙?yōu)先”把隨機寫轉(zhuǎn)換成內(nèi)存中的有序結(jié)構(gòu)再通過批量刷盤和后臺合并來持久化。代價是讀放大和寫放大。這個取舍在筆試?yán)锝?jīng)常以對比題出現(xiàn)你要答出“為什么RocksDB和HBase都選LSM”核心就是高吞吐寫入場景下LSM的代價可以接受而B樹的隨機寫代價可能先拖垮你。2.2 跳表與有序數(shù)據(jù)結(jié)構(gòu)隱藏在Redis和內(nèi)存引擎里的選擇再說跳表。Redis選跳表當(dāng)有序集合的底層實現(xiàn)筆試?yán)镆渤Ｄ贸鰜韱枴Ｌ淼暮诵氖怯枚鄬铀饕龘Q查詢速度實現(xiàn)比紅黑樹簡單而且在并發(fā)場景下更容易做細(xì)粒度鎖。對存儲開發(fā)來說你要關(guān)注的不是跳表本身而是“當(dāng)我們需要一個有序結(jié)構(gòu)同時又希望并發(fā)性能好一點時跳表是一個工程上很務(wù)實的選擇”。我在實際寫一個內(nèi)存KV引擎時也復(fù)現(xiàn)過類似方案——用跳表做主索引哈希表做熱點緩存。兩級結(jié)構(gòu)的好處是熱點數(shù)據(jù)走哈希快速命中冷數(shù)據(jù)走跳表保持有序性。筆試面到“如何設(shè)計一個內(nèi)存KV”時這種分層結(jié)構(gòu)很加分因為你有明確的取舍理由和數(shù)據(jù)支撐。2.3 索引存儲與哈希存儲的對比筆試?yán)镒钊菀妆蛔穯柕狞c索引存儲和哈希存儲也是熱搜詞里出現(xiàn)的內(nèi)容這確實是存儲開發(fā)的基礎(chǔ)概念。哈希存儲適合等值查詢索引存儲適合范圍查詢和排序。很多存儲引擎會把兩者結(jié)合例如MySQL InnoDB用B樹做聚簇索引但二級索引也要走B樹Redis主要用哈希和跳表但也沒放棄數(shù)組和鏈表。筆試卷里通常會給一張表列上幾種存儲結(jié)構(gòu)讓你填各自的時間復(fù)雜度和適用場景。我建議你復(fù)習(xí)時自己畫一個對比表哈希、數(shù)組、鏈表、跳表、B樹、LSM從查詢、寫入、范圍掃描、內(nèi)存占用、并發(fā)表現(xiàn)五個維度列一遍。這個表基本能覆蓋大多數(shù)數(shù)據(jù)結(jié)構(gòu)的考題。3. 分布式存儲系統(tǒng)背后的原理與權(quán)衡3.1 數(shù)據(jù)分布與一致性哈希從擴容聊到虛擬節(jié)點分布式存儲繞不開數(shù)據(jù)分布。筆試?yán)镆坏┝牡揭恢滦怨Ｍǔ２皇亲屇惚乘惴ǘ墙o一個場景現(xiàn)網(wǎng)有100個存儲節(jié)點數(shù)據(jù)用哈希分布某節(jié)點宕機后哪些key會受影響、怎么遷移、怎么避免雪崩。一個很常見的答題思路是先描述樸素取模方案的問題——節(jié)點增減導(dǎo)致大量key重新映射再說明一致性哈希通過哈希環(huán)和虛擬節(jié)點解決這個問題最后補充工程實踐上的細(xì)節(jié)比如虛擬節(jié)點數(shù)量選擇、數(shù)據(jù)傾斜檢測、以及基于分片而不是真實節(jié)點的遷移策略。這個回答鏈越完整越能體現(xiàn)你不是只懂概念。我在做分布式存儲運維時真遇到過某團隊把一致性哈希的虛擬節(jié)點數(shù)設(shè)得太少導(dǎo)致流量不均衡。一臺節(jié)點熱點明顯其他節(jié)點閑置。這個問題在筆試中不一定會寫但面試官一旦追問“你實際部署時怎么確認(rèn)分布是均勻的”你如果沒有真實經(jīng)驗很容易露怯。所以復(fù)習(xí)時最好補一下“如何統(tǒng)計哈希環(huán)的分布方差”“如何根據(jù)容量調(diào)整虛擬節(jié)點權(quán)重”這些實操內(nèi)容。3.2 CAP理論與副本一致性別再說“CAP三選二”分布式存儲的另一個高頻點是CAP。但很多人的理解停留在“一致性、可用性、分區(qū)容忍性只能選兩個”這其實是誤解。CAP的準(zhǔn)確表述是當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時你只能在一致性和可用性之間做選擇。網(wǎng)絡(luò)沒有分區(qū)的時候三者可以同時滿足。筆試中常見考法某存儲系統(tǒng)采用強同步復(fù)制問它在網(wǎng)絡(luò)分區(qū)時表現(xiàn)如何另一個系統(tǒng)采用異步復(fù)制問它是否滿足最終一致性。回答這類題你要能把系統(tǒng)行為映射到CAP的框架里。強同步復(fù)制在網(wǎng)絡(luò)分區(qū)時為了不丟數(shù)據(jù)會拒絕寫入也就是犧牲可用性保證一致性異步復(fù)制在分區(qū)時還能接受寫入但可能出現(xiàn)舊數(shù)據(jù)被讀到屬于犧牲強一致性換可用性最終靠重放日志達到最終一致。同時不要忽略了副本一致性里最經(jīng)典的raft/paxos。網(wǎng)易當(dāng)年筆試卷里對分布式共識考得不算特別深但一定會有一道題讓你描述“主從切換時如何保證日志不丟”。我給你的建議是自己用動畫或代碼模擬一遍Raft的選主和日志復(fù)制比死記硬背強得多。3.3 緩存層與存儲層的分工讓Redis不再只當(dāng)“加速器”筆試卷里的緩存題通常不會只問Redis的基本用法而是把緩存當(dāng)作存儲系統(tǒng)的一部分來考。比如一張典型架構(gòu)圖客戶端 - 緩存集群 - 存儲集群然后問你緩存擊穿、緩存穿透、緩存雪崩的處理手段。這里要注意的是存儲開發(fā)工程師看緩存視角和業(yè)務(wù)開發(fā)不太一樣。業(yè)務(wù)開發(fā)關(guān)心命中率和數(shù)據(jù)一致性存儲開發(fā)關(guān)心的是緩存集群和存儲集群之間的連接管理、緩存節(jié)點故障時的降級策略、以及緩存閾值抖動對底層存儲的沖擊。我在實際運維中就遇到過緩存集群因為帶寬打滿導(dǎo)致所有請求直接穿透到對象存儲把底層IO打掛的情況。所以筆試答題時如果你能把視角從“Redis命令”提升到“緩存作為存儲前級保護機制”就能拉開和普通候選人的差距。4. 對象存儲與文件存儲云計算場景下的必考應(yīng)用4.1 從頁式存儲到對象存儲一次架構(gòu)演進熱搜詞里有“對象存儲服務(wù)”“NAS存儲”“分布式存儲”這些概念在網(wǎng)易筆試卷里會以各類場景題出現(xiàn)。對象存儲本質(zhì)上是把數(shù)據(jù)當(dāng)作“對象”來管理每個對象有唯一的key附帶元數(shù)據(jù)存儲在扁平化命名空間中。這樣的設(shè)計天然適合海量非結(jié)構(gòu)化數(shù)據(jù)比如圖片、視頻、日志備份。筆試?yán)镉幸坏澜?jīng)典設(shè)計題讓你設(shè)計一個簡單的對象存儲系統(tǒng)支持put、get、delete、list。你至少要回答出幾個關(guān)鍵決策數(shù)據(jù)在物理節(jié)點上怎么分片元數(shù)據(jù)存在哪里小文件和大文件的處理策略是否一致上傳過程中斷后如何斷點續(xù)傳。這里建議你補充S3 API的熟悉程度因為很多互聯(lián)網(wǎng)公司的對象存儲都是兼容S3接口的網(wǎng)易NOS也不例外。我當(dāng)時復(fù)盤這道題時會把方案分成三條路徑控制面、數(shù)據(jù)面、元數(shù)據(jù)面。控制面負(fù)責(zé)權(quán)限校驗和路由數(shù)據(jù)面負(fù)責(zé)把對象落到磁盤或分布式文件系統(tǒng)上元數(shù)據(jù)面用獨立的數(shù)據(jù)庫或KV保存對象與數(shù)據(jù)塊的映射。這樣拆解之后即使面試官再追問“你的系統(tǒng)怎么支撐億級對象”你也可以在三個面上分別擴展。4.2 分布式文件系統(tǒng)的元數(shù)據(jù)管理文件存儲和對象存儲很多原理是相通的但元數(shù)據(jù)管理更復(fù)雜。分布式文件系統(tǒng)里文件被拆成多個數(shù)據(jù)塊分布在多個節(jié)點上元數(shù)據(jù)要記錄文件到數(shù)據(jù)塊的映射以及數(shù)據(jù)塊到物理節(jié)點的映射。這個映射表一旦膨脹就成了性能瓶頸。筆試卷里關(guān)于文件系統(tǒng)的題一般會圍繞“元數(shù)據(jù)服務(wù)怎么擴展”展開。經(jīng)典方案有幾種元數(shù)據(jù)分片按目錄或哈希分散到不同元數(shù)據(jù)服務(wù)器引入緩存層把熱點元數(shù)據(jù)放在內(nèi)存或者采用無中心架構(gòu)用分布式KV存儲元數(shù)據(jù)。每一種方案都對應(yīng)不同的一致性代價答題時要把權(quán)衡說出來而不是只堆方案名。4.3 小文件合并與大文件切片的取舍邏輯對象存儲場景里小文件多是一個普遍痛點。每個文件都有獨立的元數(shù)據(jù)如果100萬張小圖片各占一個對象元數(shù)據(jù)服務(wù)的壓力會非常大而且小文件在磁盤上的存儲效率也低。常見的解法是把小文件合并成大文件用“數(shù)據(jù)塊偏移量”的方式索引而在上傳大文件時又要做切片并發(fā)上傳提高吞吐和斷點續(xù)傳能力。筆試卷如果讓你設(shè)計“一個支持文件上傳的存儲系統(tǒng)”你最好主動提到小文件合并和大文件切分這組對稱設(shè)計。這會體現(xiàn)你真的處理過存儲容量和性能問題而不是只會調(diào)用SDK。我個人的經(jīng)驗是小文件合并的塊大小一般設(shè)置在4MB到64MB之間具體看對象平均大小和底層文件系統(tǒng)的塊大小大文件切片則與網(wǎng)絡(luò)環(huán)境和并發(fā)數(shù)相關(guān)不能盲目切小否則元數(shù)據(jù)本身會變成新的瓶頸。5. IO模型與性能調(diào)優(yōu)把系統(tǒng)設(shè)計落到工程層面5.1 零拷貝、直接IO與頁緩存存儲性能題的主角對象存儲和分布式存儲的性能瓶頸很多不在CPU而在IO路徑。筆試卷里常見的一道題是讀文件并發(fā)送到網(wǎng)絡(luò)這個過程中數(shù)據(jù)從磁盤到網(wǎng)卡拷貝了幾次如何減少拷貝次數(shù)。這里引出零拷貝、mmap、sendfile等概念。面試官想聽到的回答是傳統(tǒng)readwrite會經(jīng)歷內(nèi)核態(tài)到用戶態(tài)兩次拷貝而mmap可以少一次sendfile可以做到真正意義上的“內(nèi)核態(tài)完成數(shù)據(jù)傳輸”。存儲開發(fā)里零拷貝常用于對象存儲的下載鏈路因為數(shù)據(jù)不需要經(jīng)過業(yè)務(wù)進程的加工直接透傳即可。但在寫路徑里零拷貝就不一定合適因為你需要對數(shù)據(jù)做校驗和加密必須經(jīng)過用戶態(tài)。5.2 OS頁緩存的選擇與落盤策略存儲系統(tǒng)要不要用頁緩存取決于一致性要求。很多分布式存儲為了數(shù)據(jù)安全會強制寫盤后才返回成功這樣即使節(jié)點宕機數(shù)據(jù)也不丟但代價是每次寫入都伴隨一次fsync性能大幅下降。常見的折中方案是用組提交或批量刷盤來攤薄fsync代價同時在內(nèi)存里保留一個未提交窗口窗口大小直接影響宕機丟數(shù)據(jù)的概率。筆試卷如果考到“怎么保證寫入不丟同時提升性能”你可以答WAL加批量刷盤。WAL先順序?qū)懭罩驹佼惒剿?shù)據(jù)頁崩潰恢復(fù)時通過日志重放未完成的事務(wù)。這個設(shè)計既能保證事務(wù)持久化又能避免每次寫操作都隨機落盤。在答題時我建議你畫一個時間軸把寫入請求、日志落盤、數(shù)據(jù)落盤、用戶響應(yīng)幾個節(jié)點標(biāo)出來邏輯會非常清晰。5.3 并發(fā)模型與多線程存儲服務(wù)的常見陷阱存儲服務(wù)通常需要支撐大量并發(fā)連接所以IO模型的選擇很重要。筆試?yán)锟赡軙o一個線程模型讓你指出它的瓶頸。比如一個簡單的“每請求一線程”模型在高并發(fā)下會因線程上下文切換和內(nèi)存開銷而崩潰更優(yōu)的方案是Reactor模型或Proactor模型。同時要考慮鎖競爭。在多線程寫同一個存儲引擎時如果全部串行化吞吐上不去但如果只加粗粒度鎖又可能出現(xiàn)偽共享和長尾延遲。常見的優(yōu)化方向是分片鎖、無鎖隊列、以及避免在IO路徑上做耗時操作。你在答題時最好用具體數(shù)字說明問題比如“1000并發(fā)下每請求50ms延遲單線程只能處理20請求每秒改用8線程Reactor后能達到150”。6. 真題實戰(zhàn)復(fù)盤我把當(dāng)年的幾道典型題重新做了一遍6.1 場景題設(shè)計一個日志存儲系統(tǒng)怎么答比較穩(wěn)我印象很深的一道筆試題是給一個日志系統(tǒng)每天產(chǎn)生數(shù)十億條日志需要支持寫入和按時間范圍查詢問你如何設(shè)計存儲層。我的答題框架分四步第一日志寫入是順序追加型優(yōu)先考慮LSM Tree或類Kafka的分段日志結(jié)構(gòu)第二為了支持時間范圍查詢必須建立時間索引和偏移量索引可以考慮用倒排索引或時間分桶第三日志數(shù)據(jù)生命周期短冷數(shù)據(jù)要定期歸檔到對象存儲降低本地存儲成本第四查詢接口要支持分頁和游標(biāo)避免一次拉取過多數(shù)據(jù)導(dǎo)致內(nèi)存溢出。這四步寫下來比單純回答“我選HBase”要完整得多。現(xiàn)場寫代碼的時候我會先定義幾個核心接口append(log)、query(startTime, endTime, offset, limit)、archive(beforeTime)。然后給出一個簡化版實現(xiàn)用TreeMap存內(nèi)存索引用隊列做批量寫盤。代碼不需要很復(fù)雜但要讓面試官看到你有“先定接口再定實現(xiàn)”的工程習(xí)慣。6.2 手寫一個簡化的LSM存儲合并流程筆試卷里偶爾會讓手寫一個小型KV存儲核心考點是LSM的寫入流程和合并觸發(fā)條件。這個題不算難但比較容易寫漏。我一般會實現(xiàn)三個模塊內(nèi)存表、WAL、SSTable列表。寫入時先追加WAL再寫入內(nèi)存表內(nèi)存表超過閾值后切換為不可變內(nèi)存表后臺刷盤生成SSTable當(dāng)SSTable數(shù)量或大小達到閾值觸發(fā)合并將多個SSTable按key歸并為一個更大的SSTable。刪除時插入tombstone標(biāo)記合并時清理。這套流程用Java或C寫核心方法大概幾十行就能完成但足夠展示出你對存儲引擎內(nèi)部機制的理解。這里要特別注意一點合并過程會消耗IO和CPU所以需要控制觸發(fā)頻率。常見策略包括根據(jù)SSTable數(shù)量和大小雙重判斷或者根據(jù)讀放大率動態(tài)調(diào)整。這個細(xì)節(jié)在筆試?yán)锊灰欢〞鞔_要求但你在注釋或額外說明里寫上會讓面試官覺得你有工程經(jīng)驗。6.3 對象存儲上傳接口的完整實現(xiàn)思路最后一道類似附加題的場景設(shè)計對象存儲的上傳接口支持?jǐn)帱c續(xù)傳和秒傳。斷點續(xù)傳的經(jīng)典做法是客戶端將文件切片每個切片獨立上傳服務(wù)端記錄切片狀態(tài)全部完成后合并。秒傳則依賴哈希校驗客戶端先上傳文件的MD5或SHA1服務(wù)端檢查是否已存在相同哈希的對象如果存在直接返回成功省去重復(fù)上傳的流量和時間。這道題在筆試中主要考察“你是否了解對象存儲API背后的邏輯”。很多同學(xué)用過OSS或S3的SDK但不一定了解分片上傳的完整生命周期。我建議你把createMultipartUpload、uploadPart、completeMultipartUpload三個接口的流程背熟并補充說明每個階段服務(wù)端需要記錄的元數(shù)據(jù)uploadId、partNumber、etag、偏移量。這樣遇到類似的筆試題不管怎么問都能接得住。7. 常見問題與備考誤區(qū)我見過太多人倒在這些坑里7.1 為什么你背了很多題筆試還是過不了校招筆試和面試不一樣它更強調(diào)“在有限時間內(nèi)快速給出條理清晰、邏輯嚴(yán)謹(jǐn)?shù)姆桨浮薄：芏嗤瑢W(xué)背書式復(fù)習(xí)遇到具體場景就不知道怎么遷移。比如學(xué)過LSM Tree但面對“日志系統(tǒng)怎么設(shè)計”時還是答偏到MySQL上去了。我建議的備考方式是每學(xué)一個存儲組件都問自己三個問題——它解決什么問題、它的核心原理是什么、如果讓我寫一個簡化版我會怎么設(shè)計。這三問答清楚相關(guān)考點基本不會丟。我當(dāng)時復(fù)習(xí)Redis就逼自己寫了一個簡單的跳表版有序集合復(fù)習(xí)RocksDB就手動模擬過一次SSTable合并。這個過程非常耗時但對筆試的幫助遠(yuǎn)超刷十套題。7.2 項目經(jīng)驗怎么寫才會讓面試官覺得你懂存儲網(wǎng)申階段通常要寫項目經(jīng)歷很多同學(xué)把“用過Redis”“部署過HDFS”寫成核心亮點這其實很難打動面試官。真正有說服力的寫法是描述你在項目中遇到什么樣的存儲瓶頸你如何定位和解決最終帶來什么量化收益。我輔導(dǎo)過一位同學(xué)他在實驗室做過一個圖像檢索系統(tǒng)項目本身不復(fù)雜但他把重點放在“向量數(shù)據(jù)如何存儲和檢索”上提到用了FAISS做近鄰搜索并用LSM結(jié)構(gòu)管理增量向量效果比直接用暴力搜索好很多。面試官對這個項目印象非常深因為它不是“用過”而是“理解并改進過”。如果你有類似的項目經(jīng)歷一定要挖掘出存儲層面的細(xì)節(jié)而不是停留在業(yè)務(wù)功能描述。7.3 關(guān)于經(jīng)典題的標(biāo)準(zhǔn)答案不要只停留在會背存儲方向有一個特點同一道題每個技術(shù)團隊理解的“標(biāo)準(zhǔn)答案”都不一樣。同樣是“怎么保證Redis和MySQL數(shù)據(jù)一致”有人會聊刪除緩存策略有人會聊binlog消費還有人會聊分布式事務(wù)。這些方向沒有對錯但你要能結(jié)合題目上下文給出合理的分析路徑。筆試卷最怕的是“看起來答了很多但沒有邏輯主線”。我自己的習(xí)慣是遇到任何設(shè)計題先用一句話寫出“核心目標(biāo)”再往下拆解“約束條件”最后才給“方案選型”。拿一個例子來說目標(biāo)是“設(shè)計一個支持PB級數(shù)據(jù)的存儲系統(tǒng)”約束是“讀寫比例10:1、可用性99.99%”那方案自然會偏向數(shù)據(jù)分片和副本冗余而不是單機優(yōu)化。有了這條主線即使某一個小點想不全面整體分?jǐn)?shù)也不會太低。8. 資料清單與備賽方向這些年我用下來很順手的學(xué)習(xí)路徑8.1 核心書籍與開源項目怎么讀才能事半功倍如果你想系統(tǒng)性地準(zhǔn)備云計算存儲方向我比較推薦幾條主線。第一《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計》DDIA作為總綱把存儲結(jié)構(gòu)、復(fù)制、分區(qū)、事務(wù)、一致性都過一遍第二MIT 6.824的視頻和lab作為分布式系統(tǒng)實操訓(xùn)練第三讀一個開源存儲引擎的源碼不用太多選RocksDB或LevelDB其中一個就行。讀源碼不是讓你從頭到尾一行行看而是把核心模塊抽出來比如RocksDB的memtable怎么轉(zhuǎn)SSTable、compaction怎么觸發(fā)、WAL怎么管理。看懂了筆試和面試?yán)锏拇鎯σ骖}基本都能穩(wěn)定發(fā)揮。如果你有余力建議把Mini-LSM這類教學(xué)項目的實驗做一遍它會在限制條件下逼你實現(xiàn)一個小型LSM存儲做完之后對整條鏈路的理解會非常具象。8.2 一套實用的復(fù)習(xí)時間表按周拆解不焦慮我常建議準(zhǔn)備校招的同學(xué)把存儲方向的復(fù)習(xí)周期定為六周。第一周“打地基”過一遍操作系統(tǒng)、網(wǎng)絡(luò)、數(shù)據(jù)結(jié)構(gòu)的重點第二到三周“專攻分布式理論”CAP、Raft、數(shù)據(jù)復(fù)制、分片等每天配合一道場景題練習(xí)第四周“深入存儲引擎”寫一個簡化版LSM或B樹的內(nèi)存模型第五周“刷真題和模擬題”重點練設(shè)計題和代碼題第六周“模擬面試”找朋友或自己對著題目口述答案訓(xùn)練表達和邏輯。當(dāng)然這不是唯一的時間表你可以根據(jù)自己基礎(chǔ)調(diào)整。但有一點很重要不要每天只輸入不輸出一定要用代碼或文字把學(xué)到的知識固化下來。我在準(zhǔn)備校招時每周末會把本周學(xué)到的核心知識點寫成一篇復(fù)盤文章或者畫成一張系統(tǒng)架構(gòu)圖。這個過程很痛苦但堅持下來筆試遇到陌生題也不慌因為你已經(jīng)習(xí)慣了“拆解組裝”的思考方式。