聊到 HDFS 的寫數(shù)據(jù)流程大多數(shù)人的第一反應(yīng)是這不就是面試常考的那條鏈路嗎客戶端先問 NameNode 要塊拿到一串 DataNode 列表然后按順序把數(shù)據(jù)丟過(guò)去最后一個(gè)節(jié)點(diǎn)寫完了往回 ACK……但真正到了生產(chǎn)環(huán)境你會(huì)發(fā)現(xiàn)這條鏈路遠(yuǎn)沒有八股文里說(shuō)的那么平順。你可能會(huì)遇到寫入突然卡住、塊副本數(shù)長(zhǎng)期少 1、集群明明有空間但寫文件卻報(bào)超時(shí)——這些現(xiàn)象的答案都藏在源碼里。最近我把 HDFS 寫路徑上的核心代碼重新過(guò)了一遍從 DFSClient 到 DataNode 的 BlockReceiver整理出了這篇更偏“為什么”的解讀。適合兩類人看一是正準(zhǔn)備深入大數(shù)據(jù)源碼的同學(xué)二是被線上寫入問題折磨過(guò)、想搞明白底層機(jī)制的同學(xué)。1. 寫數(shù)據(jù)流程全貌三大角色與一條流水線1.1 先把整體鏈路畫在腦子里讀源碼之前先看整體否則細(xì)節(jié)容易把人淹沒。HDFS 寫數(shù)據(jù)涉及三個(gè)角色客戶端負(fù)責(zé)提交數(shù)據(jù)和接收確認(rèn)NameNode 負(fù)責(zé)元數(shù)據(jù)、分配塊、登記管道信息DataNode 負(fù)責(zé)真正把數(shù)據(jù)落到磁盤。用生活化類比就是“快遞下單—倉(cāng)庫(kù)分配—分撥運(yùn)輸”三個(gè)環(huán)節(jié)環(huán)環(huán)相扣。更具體一點(diǎn)整條鏈路大致是這樣的客戶端調(diào)用 create 請(qǐng)求到 NameNodeNameNode 建立文件元數(shù)據(jù)和租約。客戶端攢了一批數(shù)據(jù)后向 NameNode 申請(qǐng)第一個(gè)塊以及一組副本節(jié)點(diǎn)?？蛻舳伺c第一個(gè) DataNode 建立連接第一個(gè) DataNode 再連著第二個(gè)第二個(gè)再連著第三個(gè)形成一個(gè)管道?？蛻舳税褦?shù)據(jù)切成 chunk、組裝成 packet沿管道逐級(jí)向下發(fā)送每個(gè)節(jié)點(diǎn)邊收邊落盤邊向下傳。最后一個(gè) DataNode 寫完一個(gè) packet 后逐級(jí)向上返回 ACK直到客戶端收到確認(rèn)?？蛻舳耸盏酱_認(rèn)后繼續(xù)發(fā)下一個(gè) packet直到塊寫滿塊寫滿后再次向 NameNode 申請(qǐng)新塊循環(huán)往復(fù)直到整個(gè)文件寫完并關(guān)閉。這條鏈路最關(guān)鍵的不對(duì)稱點(diǎn)在于數(shù)據(jù)是鏈?zhǔn)絺鬏數(shù)腁CK 卻是反向?qū)訉邮栈氐摹？蛻舳税l(fā)的不是“三份廣播數(shù)據(jù)”而是“一份數(shù)據(jù)在管道里被接力復(fù)制”。這個(gè)設(shè)計(jì)和很多人直覺里想的完全不一樣但它是整個(gè) HDFS 吞吐能力的基石。1.2 為什么采用流水線而不是三份同時(shí)發(fā)理論上寫入三副本有兩種方案廣播方案客戶端同時(shí)向三個(gè) DataNode 發(fā)送數(shù)據(jù)每個(gè)節(jié)點(diǎn)各收一份。流水線方案客戶端只發(fā)給第一個(gè)節(jié)點(diǎn)第一個(gè)節(jié)點(diǎn)邊收邊傳給第二個(gè)第二個(gè)再傳給第三個(gè)。廣播方案看起來(lái)直接但有個(gè)致命問題客戶端出口帶寬變成了瓶頸。假設(shè)單客戶端出口帶寬是 1Gbps寫三副本時(shí)每份能分到的帶寬只有三分之一整體吞吐被壓到三分之一。而且副本數(shù)越往后擴(kuò)展這個(gè)問題越嚴(yán)重副本從 3 擴(kuò)到 5客戶端就要同時(shí)扛 5 個(gè)連接的寫流量。流水線方案的聰明之處在于客戶端永遠(yuǎn)只維護(hù)“一個(gè)連接”的寫帶寬下游節(jié)點(diǎn)之間的復(fù)制走的是集群內(nèi)部網(wǎng)絡(luò)。DataNode 之間的帶寬通常比客戶端到集群的帶寬更充足所以整體吞吐不受副本數(shù)線性拖累。你用公司文件服務(wù)器類比把同一份資料發(fā)給三個(gè)人挨個(gè)拷貝當(dāng)然比同時(shí)開三個(gè)窗口對(duì)拷要穩(wěn)得多尤其當(dāng)你本機(jī)的網(wǎng)卡才是瓶頸的時(shí)候。另外流水線方案天然支持異構(gòu)節(jié)點(diǎn)。如果管道里某個(gè)節(jié)點(diǎn)寫盤慢它只會(huì)暫緩自己這一段的傳遞不會(huì)像廣播方案那樣讓三個(gè)節(jié)點(diǎn)同時(shí)等一個(gè)慢客戶端。這就是架構(gòu)設(shè)計(jì)里典型的“以局部排隊(duì)換取整體吞吐”。1.3 理清寫流程里對(duì)應(yīng)的核心源碼類讀源碼最怕一頭扎進(jìn)某個(gè)類里出不來(lái)。按我個(gè)人的閱讀習(xí)慣我會(huì)先拉一張類與職責(zé)的清單再按調(diào)用順序去跟。源碼類所在組件核心職責(zé)DFSClient客戶端發(fā)起 create、addBlock、complete 等 RPC 請(qǐng)求是客戶端入口DFSOutputStream客戶端數(shù)據(jù)緩沖、按 chunk 切分、計(jì)算校驗(yàn)和、組裝 packetDataStreamer客戶端寫數(shù)據(jù)的核心線程負(fù)責(zé)申請(qǐng)塊、建立管道、發(fā)送數(shù)據(jù)、處理 ACKPacket客戶端一個(gè)傳輸單元封裝包含 header、數(shù)據(jù)體、校驗(yàn)信息BlockReceiverDataNode接收管道下發(fā)的數(shù)據(jù)執(zhí)行落盤、校驗(yàn)、向下游轉(zhuǎn)發(fā)DataNode 的 XceiverServerDataNode管理接收連接的線程池每個(gè)連接對(duì)應(yīng)一個(gè) BlockReceiver如果只挑一條主線來(lái)讀我建議從 DFSOutputStream 的 write 方法入手順著數(shù)據(jù)對(duì)象進(jìn)入 DataStreamer.run()再跟著 packet 走到 BlockReceiver。這條路走通之后基本就掌握了整個(gè)寫路徑的 80%。2. 寫前準(zhǔn)備從 create 到選中三個(gè) DataNode2.1 第一步拿到租約而不是直接寫很多人讀寫流程時(shí)習(xí)慣直接跳到“申請(qǐng)塊”但忽略了 create 階段有個(gè)容易被帶過(guò)的機(jī)制——租約Lease。為什么 HDFS 要搞租約因?yàn)樗辉试S兩個(gè)客戶端同時(shí)寫同一個(gè)文件。如果沒有租約兩個(gè)任務(wù)同時(shí)往一個(gè)文件寫數(shù)據(jù)會(huì)造成塊長(zhǎng)度不一致、文件內(nèi)容交叉錯(cuò)亂NameNode 根本沒法判斷誰(shuí)是“合法寫入方”。租約本質(zhì)上就是個(gè)寫鎖文件創(chuàng)建時(shí)客戶端會(huì)拿到一個(gè)持有者標(biāo)記相當(dāng)于在文檔協(xié)作工具里把文件“鎖定編輯”。源碼里租約相關(guān)的邏輯集中在 LeaseManager?？蛻舳藢懭脒^(guò)程中會(huì)定期續(xù)約一旦租約超過(guò)硬限制仍未續(xù)約NameNode 就會(huì)認(rèn)為寫方已經(jīng)“失聯(lián)”從而觸發(fā)租約恢復(fù)流程把文件從“寫了一半”的狀態(tài)拉回一致狀態(tài)。這個(gè)機(jī)制在后面故障恢復(fù)章節(jié)還要細(xì)講這里先記住一個(gè)結(jié)論create 不只建文件還在確立“誰(shuí)能寫”的唯一身份。2.2 NameNode 分配塊時(shí)怎么挑節(jié)點(diǎn)客戶端申請(qǐng)塊時(shí)NameNode 會(huì)按機(jī)架感知策略選擇副本放置節(jié)點(diǎn)。默認(rèn)三副本時(shí)策略是第 1 個(gè)副本如果客戶端本身就在某個(gè) DataNode 上就選該節(jié)點(diǎn)實(shí)現(xiàn)本地寫否則隨機(jī)選一個(gè)節(jié)點(diǎn)。第 2 個(gè)副本放到與第 1 個(gè)副本不同機(jī)架的節(jié)點(diǎn)。第 3 個(gè)副本放到與第 2 個(gè)副本相同機(jī)架內(nèi)的另一節(jié)點(diǎn)。也就是說(shuō)最終形態(tài)是“兩個(gè)副本在同一個(gè)機(jī)架另一個(gè)副本跨機(jī)架”。這樣設(shè)計(jì)的核心是平衡可靠性與網(wǎng)絡(luò)開銷。如果三個(gè)副本放三個(gè)機(jī)架機(jī)架間帶寬消耗會(huì)明顯增大如果三個(gè)副本放同一個(gè)機(jī)架一個(gè)機(jī)架掉電就丟所有副本。兩兩一組跨機(jī)架既承受住機(jī)架級(jí)故障又控制了跨機(jī)架流量。順帶說(shuō)一個(gè)容易被誤解的點(diǎn)機(jī)架感知要生效必須配置好網(wǎng)絡(luò)拓?fù)淠_本。如果你沒配機(jī)架信息NameNode 會(huì)把所有節(jié)點(diǎn)當(dāng)作同一個(gè)機(jī)架副本放置策略退化成隨機(jī)打散可靠性和性能都會(huì)打折。線上集群如果發(fā)現(xiàn)寫放大異常先查這個(gè)配置。2.3 從“拿到節(jié)點(diǎn)”到“建立管道”之間還有一步登記客戶端向 NameNode 申請(qǐng)到塊和 DataNode 列表之后并不是直接拿著列表去連接。DataStreamer 會(huì)先通過(guò) RPC 向 NameNode 發(fā)起一次寫塊登記請(qǐng)求把“塊號(hào) 副本節(jié)點(diǎn)列表 管線信息”登記進(jìn) NameNode 的 blocksMap。這一步很容易被忽略但它的意義很實(shí)際NameNode 需要知道當(dāng)前正在寫的塊屬于哪個(gè)文件、由哪些節(jié)點(diǎn)承載。如果缺少這步登記寫入過(guò)程中客戶端讀文件時(shí)NameNode 可能返回“塊不存在”或者“副本位置不完整”DataNode 匯報(bào)塊狀態(tài)時(shí)NameNode 也會(huì)因?yàn)檎也坏綄?duì)應(yīng)塊而拒絕確認(rèn)。這也是為什么我們能看到寫了一半的塊狀態(tài)是 UNDER_CONSTRUCTION而不是 COMPLETED。它表示這個(gè)塊已經(jīng)分配、已經(jīng)有節(jié)點(diǎn)在寫了但還沒完成最終確認(rèn)。2.4 寫前參數(shù)與觀察手段兩個(gè)最基礎(chǔ)的參數(shù)必須清楚因?yàn)楹芏嗉赫{(diào)優(yōu)都從它們開始dfs.blocksize默認(rèn) 134217728 字節(jié)即 128MB。決定一個(gè)塊寫多大后切換新塊。dfs.replication默認(rèn) 3。決定每個(gè)塊有幾份副本。注意dfs.blocksize 調(diào)整只影響調(diào)整之后新創(chuàng)建的文件已存在文件不會(huì)因?yàn)閰?shù)變化而重新切塊。副本數(shù)也一樣降低 replication 只對(duì)后續(xù)新建塊生效存量塊需要額外觸發(fā)復(fù)制任務(wù)或等待后臺(tái)線程調(diào)整。想觀察這個(gè)階段是否正常最直接的辦法是打開客戶端 debug 日志或者直連 NameNode 的 RPC 日志看 addBlock 調(diào)用頻率。正常情況下客戶端寫一個(gè)大文件時(shí)addBlock 請(qǐng)求是“寫一塊、申請(qǐng)一塊”的節(jié)奏而不是開始時(shí)就全部申請(qǐng)完。3. 數(shù)據(jù)真正上路Packet 的制造、發(fā)送與 ACK3.1 數(shù)據(jù)如何被切成 chunk 與 packet走進(jìn) DFSOutputStream 的 write 方法之后你會(huì)看到一個(gè)非常工程化的細(xì)節(jié)用戶數(shù)據(jù)不是從用戶態(tài)直接進(jìn)入網(wǎng)絡(luò)而是先被切割成兩級(jí)小單元。第一級(jí)是 chunk。默認(rèn) chunkSize 是 512 字節(jié)每個(gè) chunk 后面附帶 4 字節(jié)的 CRC32 校驗(yàn)和兩者組成一個(gè)最小的“校驗(yàn)單元”。第二級(jí)是 packet。默認(rèn)大小是 64KB一個(gè) packet 里裝了若干個(gè) chunk 單元。也就是說(shuō)客戶端把一大段業(yè)務(wù)數(shù)據(jù)先按 512 字節(jié)切片每片做一次校驗(yàn)然后攢夠 64KB 封裝成一個(gè) packet 發(fā)往管道。為什么搞兩級(jí)而不直接以塊為單位做校驗(yàn)答案在故障定位粒度上。如果整塊 128MB 只在最后做一次校驗(yàn)一旦發(fā)現(xiàn)有壞數(shù)據(jù)你無(wú)法知道是哪里壞了只能整塊重傳或整塊丟棄代價(jià)極大。按 512 字節(jié)切片后任何一個(gè) chunk 校驗(yàn)失敗都能精確定位到具體位置恢復(fù)時(shí)只需重傳這一小片。而 packet 定在 64KB是為了平衡網(wǎng)絡(luò)傳輸效率與確認(rèn)延遲——包太多會(huì)增加 ACK 往返次數(shù)包太大會(huì)讓接收方緩沖壓力變大。3.2 DataStreamer 線程與兩個(gè)隊(duì)列的關(guān)系繼續(xù)深挖你會(huì)發(fā)現(xiàn) DFSOutputStream 內(nèi)部維護(hù)了兩個(gè)包隊(duì)列dataQueue存放已經(jīng)組裝好、等待發(fā)送的 packet。ackQueue存放已經(jīng)發(fā)送出去、正在等待管道確認(rèn)的 packet。DataStreamer 是一個(gè)獨(dú)立的后臺(tái)線程它不斷從 dataQueue 里取出 packet沿著管道發(fā)送給第一個(gè) DataNode然后將這個(gè) packet 放入 ackQueue。當(dāng)管道逐級(jí)返回 ACK 后DataStreamer 再?gòu)?ackQueue 中移除對(duì)應(yīng) packet 并確認(rèn)發(fā)送成功。為什么非要有一個(gè)單獨(dú)線程做這件事如果把網(wǎng)絡(luò)發(fā)送邏輯直接放在用戶 write 調(diào)用里一旦某個(gè) DataNode 響應(yīng)慢用戶線程就會(huì)阻塞在 write 上業(yè)務(wù)代碼被迫等下等網(wǎng)絡(luò)。單獨(dú)線程讓網(wǎng)絡(luò)發(fā)送異步化用戶 write 只要把數(shù)據(jù)復(fù)制進(jìn)緩沖區(qū)、組裝成 packet 就能返回真正落盤和確認(rèn)的節(jié)奏由后臺(tái)線程控制。這樣寫峰值到來(lái)時(shí)緩沖區(qū)能起到平滑作用不會(huì)因?yàn)閱未尉W(wǎng)絡(luò)抖動(dòng)把業(yè)務(wù)線程卡死。3.3 管道建立時(shí)的握手細(xì)節(jié)管道不是客戶端直接“把所有節(jié)點(diǎn)拉一個(gè)群”而是逐級(jí)建立的?？蛻舳讼冗B接第一個(gè) DataNode第一個(gè) DataNode 接收到寫塊請(qǐng)求后會(huì)再向第二個(gè) DataNode 發(fā)起連接并傳遞握手信息第二個(gè)再向下連第三個(gè)。最終所有節(jié)點(diǎn)串成一條鏈。握手過(guò)程中傳遞的信息包括塊 ID、副本節(jié)點(diǎn)列表、客戶端 ID、管線 ID、存儲(chǔ)類型限制等。這些信息有幾個(gè)關(guān)鍵用途節(jié)點(diǎn)需要知道自己是第幾個(gè)副本節(jié)點(diǎn)需要知道完整的副本列表以便后續(xù)塊匯報(bào)管線 ID 用來(lái)區(qū)分不同客戶端建立的寫連接避免數(shù)據(jù)串線。如果握手階段任何一個(gè)下游節(jié)點(diǎn)連不上客戶端不會(huì)傻等。它會(huì)觸發(fā)管道重建邏輯把壞節(jié)點(diǎn)從列表里剔除要么用一個(gè)新節(jié)點(diǎn)補(bǔ)位要么直接把管道縮短然后重新協(xié)調(diào)整個(gè)握手流程。3.4 ACK 的機(jī)制先到者不算成功每個(gè) packet 都攜帶一個(gè)序號(hào)。DataNode 寫入一個(gè) packet 后必須等下游節(jié)點(diǎn)也確認(rèn)寫成功了才能向上游返回 ACK。換句話說(shuō)ACK 不是“我收到了”而是“我和我下游所有節(jié)點(diǎn)都寫成功了”。這個(gè)設(shè)計(jì)非常關(guān)鍵。對(duì)客戶端來(lái)說(shuō)只要收到某個(gè) packet 的 ACK就可以確信這個(gè) packet 已經(jīng)存在于所有副本節(jié)點(diǎn)上不需要再額外對(duì)賬。它把“多副本一致性確認(rèn)”從客戶端下沉到管道內(nèi)部讓確認(rèn)邏輯變得非常純粹。反過(guò)來(lái)想如果每個(gè) DataNode 寫成功就立即回 ACK客戶端以為所有副本都寫好了實(shí)際上數(shù)據(jù)可能只寫了一兩個(gè)節(jié)點(diǎn)一旦中間節(jié)點(diǎn)故障數(shù)據(jù)完整性就無(wú)從保證。所以 ACK 必須從管道尾部逐級(jí)向上匯聚這是 HDFS 寫不丟數(shù)據(jù)的底層保障之一。3.5 塊寫滿與多塊切換一個(gè)塊寫滿后最后一個(gè) packet 會(huì)打上 lastPacketInBlock 標(biāo)記。DataStreamer 發(fā)現(xiàn)這個(gè)標(biāo)記后不會(huì)急著馬上申請(qǐng)新塊而是先等當(dāng)前管道里所有舊 packet 都收到 ACK確保當(dāng)前塊的所有數(shù)據(jù)都已確認(rèn)落到所有副本節(jié)點(diǎn)上。之后客戶端向 NameNode 發(fā)起新塊申請(qǐng)NameNode 重新按機(jī)架感知策略分配一組 DataNode。此時(shí)因?yàn)榭蛻舳丝赡苓€在同一個(gè)節(jié)點(diǎn)上第一副本依然會(huì)優(yōu)先本地化整個(gè)選點(diǎn)和管道建立流程走一遍接著寫下一個(gè)塊。很多人以為一個(gè)文件的所有塊位置是在創(chuàng)建時(shí)一次性分配好的其實(shí) HDFS 是“寫一塊、申請(qǐng)一塊”。這樣做有幾個(gè)實(shí)際好處超大文件不會(huì)長(zhǎng)時(shí)間鎖住大量塊位置信息內(nèi)存占用更可控每個(gè)塊分配時(shí)都參考當(dāng)時(shí)的節(jié)點(diǎn)負(fù)載狀態(tài)能起到寫流量均衡的作用某個(gè)節(jié)點(diǎn)故障時(shí)后續(xù)塊會(huì)自動(dòng)避開故障節(jié)點(diǎn)不需要額外干預(yù)。4. 寫的過(guò)程中出事管道重建與租約恢復(fù)4.1 單個(gè) DataNode 故障時(shí)會(huì)發(fā)生什么假設(shè)管道是 A-B-CB 在寫入過(guò)程中出現(xiàn)磁盤故障或網(wǎng)絡(luò)斷連。此時(shí)客戶端可能在發(fā)送數(shù)據(jù)時(shí)直接收到 IOException也可能是在等待 ACK 時(shí)超時(shí)。不管哪種DataStreamer 捕獲異常后會(huì)執(zhí)行一套固定的恢復(fù)流程關(guān)閉所有與故障管道相關(guān)的連接。把 ackQueue 中所有尚未確認(rèn)的 packet 重新放回 dataQueue等待重新發(fā)送。從副本列表中剔除故障節(jié)點(diǎn) B。向 NameNode 申請(qǐng)一個(gè)替代節(jié)點(diǎn)或用剩余節(jié)點(diǎn) A-C 構(gòu)建新管道。用新管道從第一個(gè)未確認(rèn)的 packet 開始重新發(fā)送。這里有一個(gè)非常重要的設(shè)計(jì)原則出錯(cuò)后不會(huì)“接著寫”而是“整段重寫”。哪怕 C 節(jié)點(diǎn)已經(jīng)收到了部分?jǐn)?shù)據(jù)HDFS 也會(huì)選擇從失敗點(diǎn)開始重傳而不是嘗試?yán)m(xù)傳。原因很現(xiàn)實(shí)續(xù)傳需要精確對(duì)齊各節(jié)點(diǎn)的數(shù)據(jù)長(zhǎng)度判斷復(fù)雜度極高而且無(wú)法保證 B 節(jié)點(diǎn)殘留數(shù)據(jù)沒有污染整段重寫雖然浪費(fèi)一點(diǎn)帶寬但能保證所有副本從同一個(gè)數(shù)據(jù)起點(diǎn)重新開始邏輯簡(jiǎn)單可靠。已經(jīng)寫了部分?jǐn)?shù)據(jù)的壞塊會(huì)后進(jìn)入塊恢復(fù)流程。NameNode 或后續(xù)備份機(jī)制會(huì)介入把一致性不足的副本標(biāo)記為待恢復(fù)最終通過(guò)重新復(fù)制來(lái)補(bǔ)齊副本數(shù)。4.2 客戶端自己掛了租約恢復(fù)節(jié)點(diǎn)故障只是寫失敗的一種另一種常見場(chǎng)景是客戶端進(jìn)程崩潰或長(zhǎng)時(shí)間僵死。這時(shí)候沒有誰(shuí)來(lái)主動(dòng)給節(jié)點(diǎn)報(bào)錯(cuò)NameNode 的租約機(jī)制就成了兜底。每個(gè)文件創(chuàng)建時(shí)都關(guān)聯(lián)了一個(gè)租約客戶端在寫的過(guò)程中需要不斷續(xù)約。如果客戶端停止續(xù)約超過(guò)租約硬限制NameNode 的租約回收器就會(huì)啟動(dòng)租約恢復(fù)流程從寫該文件的客戶端列表中找到最后接觸過(guò)的 DataNode 作為恢復(fù)參考。讓該節(jié)點(diǎn)作為主節(jié)點(diǎn)決定塊的目標(biāo)長(zhǎng)度。所有副本節(jié)點(diǎn)把塊數(shù)據(jù)截?cái)嗷驅(qū)R到這個(gè)長(zhǎng)度。塊狀態(tài)從 UNDER_CONSTRUCTION 變?yōu)?COMPLETED文件可以被正常讀取。這個(gè)流程保證了“客戶端寫一半突然掛了”不會(huì)導(dǎo)致文件永遠(yuǎn)無(wú)法訪問?；謴?fù)出來(lái)的文件可能只包含崩潰前已經(jīng)成功確認(rèn)的數(shù)據(jù)但至少整個(gè)文件是完整的、可讀的不會(huì)出現(xiàn)某個(gè)塊只有半截這種情況。4.3 冪等與重試為什么不會(huì)重復(fù)數(shù)據(jù)HDFS 客戶端和 NameNode、DataNode 之間都是 RPC 通信網(wǎng)絡(luò)超時(shí)后會(huì)自動(dòng)重試。重試機(jī)制沒問題但如果沒有冪等設(shè)計(jì)一個(gè)“創(chuàng)建塊”請(qǐng)求因?yàn)榫W(wǎng)絡(luò)重發(fā)兩次可能就會(huì)創(chuàng)建出兩個(gè)塊造成元數(shù)據(jù)錯(cuò)亂。HDFS 解決這個(gè)問題的思路是給塊引入版本戳。每個(gè)塊從創(chuàng)建開始就帶一個(gè)唯一的 generationStamp寫入過(guò)程中每經(jīng)過(guò)一次恢復(fù)或重建版本戳都會(huì)變化?？蛻舳酥卦嚂r(shí)攜帶的是舊的版本戳NameNode 或 DataNode 發(fā)現(xiàn)版本不匹配會(huì)直接拒絕舊請(qǐng)求從而避免重復(fù)寫入產(chǎn)生臟數(shù)據(jù)。讀源碼時(shí)看到 generationStamp 字段千萬(wàn)別跳過(guò)它是 HDFS 所有“重試安全”設(shè)計(jì)的根基。理解了版本戳你就明白為什么寫入過(guò)程中老副本會(huì)被新副本替代而不是簡(jiǎn)單疊加。5. 生產(chǎn)實(shí)戰(zhàn)寫入變慢與異常排查5.1 最常見的三類失敗現(xiàn)象源碼讀得再深最終還是要落到線上問題的排查上。根據(jù)我實(shí)際遇到過(guò)的情況寫路徑上最常見的異?；臼窍旅嫒惉F(xiàn)象可能根因源碼關(guān)注點(diǎn)寫文件報(bào) NotReplicatedYetException文件 complete 時(shí)副本數(shù)還沒達(dá)到最小副本數(shù)要求查看 dfs.replication.min 和 DataNode 塊上報(bào)時(shí)機(jī)寫入中途拋超時(shí)某個(gè) DataNode 磁盤 IO 卡住或網(wǎng)絡(luò)抖動(dòng)DataStreamer 的異常棧、DataNode 端 packet 接收日志塊副本長(zhǎng)期少于預(yù)期節(jié)點(diǎn)故障后管道重建成功但副本補(bǔ)充遲遲沒完成檢查文件是否一直處于 UNDER_CONSTRUCTION或是否存在 missing 塊遇到 NotReplicatedYetException很多人第一反應(yīng)是調(diào)大超時(shí)重試其實(shí)這治標(biāo)不治本。它本質(zhì)上是客戶端在 write 或 complete 時(shí)發(fā)現(xiàn)塊的有效副本數(shù)還沒有達(dá)到最小副本數(shù)。先看看是不是某個(gè) DataNode 寫盤變慢或者節(jié)點(diǎn)剛重啟還在上報(bào)塊信息。節(jié)點(diǎn)狀態(tài)穩(wěn)定后這個(gè)異常自然消失。5.2 寫入超時(shí)的常規(guī)排查路徑如果業(yè)務(wù)側(cè)反饋“寫文件特別慢”我會(huì)按下面的路徑排查打開客戶端日志找到第一個(gè) IOException 對(duì)應(yīng)的 DataNode IP。確認(rèn)這個(gè) IP 是否反復(fù)出現(xiàn)。如果固定某節(jié)點(diǎn)失敗優(yōu)先懷疑該節(jié)點(diǎn)磁盤或網(wǎng)絡(luò)。到對(duì)應(yīng) DataNode 機(jī)器上執(zhí)行 iostat、dmesg檢查磁盤是否報(bào)錯(cuò)、磁盤使用率是否接近飽和。同時(shí)查看該節(jié)點(diǎn)所在機(jī)架的交換機(jī)流量確認(rèn)是不是機(jī)架間帶寬被打滿。核心思想是“先定位到一個(gè)節(jié)點(diǎn)再查節(jié)點(diǎn)級(jí)問題”而不是一上來(lái)就調(diào)客戶端參數(shù)。如果問題源于某塊磁盤硬件故障調(diào)大 RPC 超時(shí)只會(huì)讓整個(gè)寫任務(wù)被拖得更久正確做法是讓故障節(jié)點(diǎn)下線或摘除故障盤。5.3 幾個(gè)值得記住的調(diào)優(yōu)經(jīng)驗(yàn)寫路徑上的參數(shù)不少但真正值得在生產(chǎn)環(huán)境做調(diào)整的并不多。分享幾個(gè)我踩過(guò)坑之后得出的經(jīng)驗(yàn)dfs.client.write.packet-size默認(rèn) 64KB 在絕大多數(shù)場(chǎng)景是合理的。調(diào)大會(huì)減少 packet 數(shù)量和 ACK 往返次數(shù)但會(huì)增加單個(gè) DataNode 的接收緩沖壓力。只有在跨機(jī)房專線小帶寬高延遲的場(chǎng)景下我才會(huì)考慮適當(dāng)調(diào)大。dfs.client.block.write.replace-datanode-on-failure.policy可選值 NEVER、ALWAYS、DEFAULT。NEVER 表示節(jié)點(diǎn)寫入失敗時(shí)直接讓寫失敗ALWAYS 表示總是嘗試替換壞節(jié)點(diǎn)。生產(chǎn)環(huán)境建議先保持默認(rèn)值觀察一段時(shí)間的寫失敗率再?zèng)Q定。改 NEVER 能更快暴露隱藏的壞節(jié)點(diǎn)改 ALWAYS 能提升寫可用性但可能讓副本長(zhǎng)期處于較少狀態(tài)。dfs.replication.min這個(gè)值決定一個(gè)塊最少需要幾個(gè)成功副本才算“可寫”。默認(rèn)值通常不需要?jiǎng)拥绻阌幸粋€(gè)高可靠業(yè)務(wù)希望寫失敗盡早暴露而不是在后臺(tái)慢慢補(bǔ)副本可以把它調(diào)高。配置修改示例property namedfs.client.block.write.replace-datanode-on-failure.policy/name valueNEVER/value /property注意這個(gè)配置是客戶端配置生效范圍是客戶端發(fā)起寫請(qǐng)求時(shí)讀取改了 NameNode 的配置是不生效的。5.4 帶著問題讀源碼的建議最后給想深入源碼的同學(xué)一點(diǎn)建議不要按類從頭到尾讀而是按“一個(gè) packet 從產(chǎn)生到確認(rèn)消失”這條線去追。具體路徑是從 DFSOutputStream 的 write 方法進(jìn)入看數(shù)據(jù)如何被切片、組包跟著 packet 進(jìn)入 dataQueue再看 DataStreamer 線程如何取包、發(fā)送、維護(hù) ackQueue然后跳轉(zhuǎn)到 DataNode 端找到 BlockReceiver 的接收與落盤邏輯最后回到 ACK 的產(chǎn)生與上傳路徑。把這條線走通之后你自然會(huì)弄明白為什么會(huì)有 NotReplicatedYetException、為什么管道重建要重傳未確認(rèn)的包、為什么租約恢復(fù)能解決客戶端“假死”問題。源碼不是用來(lái)背的是用來(lái)回答“線上為什么會(huì)這樣”的。最后分享一點(diǎn)個(gè)人體會(huì)。源碼讀得越多越覺得教科書里的“三步四步”只是壓縮過(guò)的骨架真正有價(jià)值的判斷都在細(xì)節(jié)里——比如為什么 ACK 要等整條管道都寫完為什么壞節(jié)點(diǎn)被替換而不是繼續(xù)湊合。如果你也想啃這塊源碼我的建議是別按類讀按“一個(gè) packet 從產(chǎn)生到確認(rèn)消失”這條線讀順著數(shù)據(jù)流走一遍比任何理論分析都管用。遇到線上寫慢的時(shí)候試試先抓客戶端日志里連續(xù)報(bào)錯(cuò)的 DataNode IP多數(shù)問題都能在十分鐘內(nèi)定位。