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