【正文】 添加INodeFileUnderConstruction的文件實(shí)例；4.每一個(gè)系統(tǒng)架構(gòu)都是搭建在一定假設(shè)上的，這些假設(shè)有些來自于實(shí)際業(yè)務(wù)的狀況，有些是因?yàn)樘焐臈l件約束，不基于假設(shè)理解設(shè)計(jì)，肯定會(huì)有失偏頗...）?？蛻舳藙t可以實(shí)例化一個(gè)該接口的代理對(duì)象，調(diào)用該接口的相應(yīng)方法，執(zhí)行一次同步的通信，傳入相應(yīng)參數(shù)，接收相應(yīng)的返回值。在GFS和HDFS的架構(gòu)中，只有文件的目錄結(jié)構(gòu)和分塊信息才會(huì)被持久化到本地磁盤上，而數(shù)據(jù)塊的位置信息則是通過動(dòng)態(tài)匯總過來的，僅僅存活在內(nèi)存數(shù)據(jù)結(jié)構(gòu)中，機(jī)器掛了，就灰飛煙滅了。Block類用于表示數(shù)據(jù)塊，而FSDataset類是數(shù)據(jù)服務(wù)器管理文件塊的數(shù)據(jù)結(jié)構(gòu)，其中，每一個(gè)FSDataset有一個(gè)FSVolumeSet。它不和主控服務(wù)和數(shù)據(jù)服務(wù)一樣，在一個(gè)獨(dú)立的進(jìn)程中提供服務(wù)，它只是以一個(gè)類庫(kù)（包）的模式存在，為用戶提供了文件讀寫、目錄操作等APIs。這種設(shè)計(jì)策略，避免了多臺(tái)服務(wù)器間即時(shí)同步數(shù)據(jù)的代價(jià)，而同時(shí)，它也使得主控服務(wù)器很可能成為整個(gè)架構(gòu)的瓶頸所在。而是存放在一個(gè)服務(wù)器集群上，由集群中的服務(wù)器，各盡其責(zé)，通力合作，提供整個(gè)文件系統(tǒng)的服務(wù)。文中所用翻譯HDFS中的術(shù)語(yǔ)GFS中的術(shù)語(yǔ)術(shù)語(yǔ)解釋主控服務(wù)器NameNodeMaster整個(gè)文件系統(tǒng)的大腦，它提供整個(gè)文件系統(tǒng)的目錄信息，并且管理各個(gè)數(shù)據(jù)服務(wù)器。首先，看它如何去實(shí)現(xiàn)文件系統(tǒng)所需的基本增刪改查的功能。我個(gè)人從上述資料中受益匪淺，而我自己要做的整理，與原始的源碼剖析有些不同，不是依照實(shí)現(xiàn)的模塊，而是基于論文的脈絡(luò)和實(shí)現(xiàn)這樣系統(tǒng)的基本脈絡(luò)來進(jìn)行的，也算，從另一個(gè)角度給出一些東西吧。幸好我們還有Open Source，還有Hadoop。Hadoop是一個(gè)基于Java實(shí)現(xiàn)的，開源的，分布式存儲(chǔ)和計(jì)算的項(xiàng)目。鑒于個(gè)人對(duì)于分布式系統(tǒng)的理解非常的淺薄，缺少足夠的實(shí)踐經(jīng)驗(yàn)，深入的問題就不班門弄斧了，僅做梳理和解析，大牛至此，可繞路而行了。然后，看它如何考慮分布式系統(tǒng)的特點(diǎn)，提供更好的容錯(cuò)性，負(fù)載平衡，等等之類的。數(shù)據(jù)服務(wù)器DataNodeChunk Server分布式文件系統(tǒng)中的每一個(gè)文件，都被切分成若干個(gè)數(shù)據(jù)塊，每一個(gè)數(shù)據(jù)塊都被存儲(chǔ)在不同的服務(wù)器上，此服務(wù)器稱之為數(shù)據(jù)服務(wù)器。其中重要的服務(wù)器包括：主控服務(wù)器（Master/NameNode），數(shù)據(jù)服務(wù)器（ChunkServer/DataNode），和客戶服務(wù)器。因此，盡量為主控服務(wù)器減負(fù)，不然它做太多的事情，就自然而然的晉升成了一個(gè)分布式文件系統(tǒng)的設(shè)計(jì)要求。當(dāng)用戶需要使用分布式文件系統(tǒng)進(jìn)行文件讀寫的時(shí)候，把客戶端相關(guān)包給配置上，就可以通過它來享受分布式文件系統(tǒng)提供的服務(wù)了。多個(gè)數(shù)據(jù)目錄，可以放在不同的磁盤上，這樣有利于加快磁盤操作的速度。每一個(gè)數(shù)據(jù)服務(wù)器啟動(dòng)后，都會(huì)向主控服務(wù)器發(fā)送注冊(cè)消息，將其上數(shù)據(jù)塊的狀況都告知于主控服務(wù)器。基于此RPC的通信模式，是一個(gè)消息拉取的流程，RPC服務(wù)器等待RPC客戶端的調(diào)用，而不會(huì)先發(fā)制人主動(dòng)把相關(guān)信息推送到RPC客戶端去。在GFS中，對(duì)文件的寫入分成追加寫和插入寫都有所支持，但是，在HDFS中僅僅支持追加寫，這大大降低了復(fù)雜性。寫日志；5.設(shè)置用戶setOwnersetOwnersetOwner1. 檢查是否有操作權(quán)限；2. 修改指定路徑下INode的權(quán)限；3. 寫日志。這種策略類似于DMA，降低了主控服務(wù)器的負(fù)載，提高了效率。相比于寫，文件的讀取實(shí)在是一個(gè)簡(jiǎn)單的過程。但是，寫入操作，則是一個(gè)一對(duì)多的流程。與讀取類似，寫入開始，會(huì)創(chuàng)建此類的實(shí)例。數(shù)據(jù)是分成一個(gè)個(gè)數(shù)據(jù)包發(fā)送的，所有寫入的內(nèi)容，被緩存在客戶端，當(dāng)寫滿64K，放入DFSOutputStream的dataQueue隊(duì)列。此外，寫入涉及到租約問題，后續(xù)會(huì)仔細(xì)的來說。畢竟，做為一個(gè)文件系統(tǒng)的使用者，在整個(gè)文件系統(tǒng)中的地位，難免有些歸于三流。定時(shí)輪詢調(diào)用ClientProtocol的renewLease方法，續(xù)簽租約。NameNode會(huì)記住此DataNode的運(yùn)行狀況，作為新的數(shù)據(jù)塊分配或是負(fù)載均衡的依據(jù)。解決策略就是：日志。在HDFS的實(shí)現(xiàn)中，F(xiàn)SEditLog類是整個(gè)日志體系的核心，提供了一大堆方便的日志寫入API，以及日志的恢復(fù)存儲(chǔ)等功能。SecondaryNameNode看上去像客戶端一樣，與NameNode之間，走著NamenodeProtocol協(xié)議。GFS與HDFS的策略相比較，前者是化整為零，后者則是批量處理，通常我們認(rèn)為，批量處理的平均效率更高一些，且相對(duì)而言，可能實(shí)現(xiàn)起來容易一些，但是，由于有間歇期，會(huì)導(dǎo)致日志的丟失，從而無法100%的將備份主控服務(wù)器的狀態(tài)與主控服務(wù)器完全同步。但是，由于網(wǎng)絡(luò)的復(fù)雜性，簡(jiǎn)單的版本信息無法保證具體內(nèi)容的一致性（因?yàn)榇税姹拘畔⑴c內(nèi)容無關(guān)，可能會(huì)出現(xiàn)版本相同，但內(nèi)容不同的狀況）。具體的算法流程，參見LeaseManager類上面的注釋。在這里說的負(fù)載均衡，是寬泛意義上的均衡過程，主要涵蓋兩個(gè)階段的事務(wù)，一個(gè)是在任務(wù)初始分配的時(shí)候盡可能合理分配，另一個(gè)是在事后時(shí)刻監(jiān)督及時(shí)調(diào)整。主要的調(diào)整其實(shí)就是一個(gè)操作，將一個(gè)數(shù)據(jù)塊從一個(gè)服務(wù)器搬遷到另一個(gè)服務(wù)器上。此類垃圾的特點(diǎn)恰恰相反，主控服務(wù)器無法直接了解到垃圾狀況，需要曲線救國(guó)。V. 總結(jié)整個(gè)分布式文件系統(tǒng)，計(jì)算系統(tǒng)，數(shù)據(jù)庫(kù)系統(tǒng)的設(shè)計(jì)理念，基本是一脈相承的。而刨去這一些，分布式文件系統(tǒng)中最大特點(diǎn)，就是文件塊的冗余存儲(chǔ)，它直接導(dǎo)致了較為復(fù)雜的寫入流程。而第二類垃圾的判定，則放在數(shù)據(jù)服務(wù)器發(fā)送其數(shù)據(jù)塊信息來的過程中，經(jīng)過與本地信息的比較，可以斷定，此數(shù)據(jù)服務(wù)器上有哪些數(shù)據(jù)塊已經(jīng)不幸淪為垃圾。具體的算法請(qǐng)自行參考源碼?；旧蟻碚f，數(shù)據(jù)塊的分配工作和備份的數(shù)量、申請(qǐng)的客戶端地址（也就是寫入者）、已注冊(cè)的數(shù)據(jù)服務(wù)器位置，密切相關(guān)。此算法可以由客戶端或者是主控服務(wù)器發(fā)起，當(dāng)客戶端在寫入一個(gè)數(shù)據(jù)包失敗后，會(huì)發(fā)起租約恢復(fù)。當(dāng)客戶端向數(shù)據(jù)服務(wù)器追加寫入數(shù)據(jù)包時(shí)，每一個(gè)數(shù)據(jù)包的數(shù)據(jù)，都會(huì)切分成512字節(jié)大小的段，作為簽名驗(yàn)證的基本單位，在HDFS中，把這個(gè)數(shù)據(jù)段稱為Chunk，即傳輸塊（注意，在GFS中，Chunk表達(dá)的是數(shù)據(jù)塊...）。哪怕各個(gè)服務(wù)器都舒舒服服的活著，也可能有各種各樣的情況導(dǎo)致網(wǎng)絡(luò)傳輸中的數(shù)據(jù)丟失或者錯(cuò)誤。整個(gè)算法涉及到NameNode和SecondaryNameNode兩個(gè)服務(wù)器，最終結(jié)果是NameNode和SecondaryNameNode都依照算法進(jìn)行前的日志生成了鏡像。為了保證日志的安全性，F(xiàn)SEditLog提供了EditLogFileOutputStream類作為寫入的承載類，它會(huì)同時(shí)開若干個(gè)本地文件，然后依次寫入，防止日志的損壞導(dǎo)致不可估量的后果。在主控服務(wù)器上，所有對(duì)文件目錄操作的關(guān)鍵步驟（具體文件內(nèi)容所處的數(shù)據(jù)服務(wù)器，是不會(huì)被寫入日志的，因?yàn)檫@些內(nèi)容是動(dòng)態(tài)建立的...），都會(huì)被寫入日志。但是，sendHeartbeat并沒有提供本地的數(shù)據(jù)塊信息給NameNode，那么主控服務(wù)器就無法知道此數(shù)據(jù)服務(wù)器應(yīng)該分配什么數(shù)據(jù)塊應(yīng)該刪除什么數(shù)據(jù)塊，那么它是如何決定的呢？答案就是DatanodeProtocol定義的另一個(gè)方法，blockReport。如果一切正常，該客戶端完成寫操作，會(huì)關(guān)閉文件，停止租約，一旦有所意外，比如文件被刪除了，客戶端犧牲了，主控服務(wù)器都會(huì)剝奪此租約，如此，來避免由于客戶端停機(jī)帶來的資源被長(zhǎng)期霸占的問題。因?yàn)?，此時(shí)此刻，在主控服務(wù)器上對(duì)應(yīng)的文件，正作為INodeFileUnderConstruction活著，僅僅