【正文】 ，因為這說明這個此處有爺，請另尋高就，從而保持了并發(fā)寫入的次序性。此流程依次延續(xù)，直到最后一級，它發(fā)送回包，反向著逐級傳遞，再次回到客戶端。然后重新回到上述流程，繼續(xù)前行。HDFS有三類服務(wù)器，每一類服務(wù)器出錯了，都有相應(yīng)的應(yīng)急策略。這個合同有一個期限，在這個期限內(nèi)，客戶端可以延長合同期限，一旦超過期限，主控服務(wù)器會強行終止此租約，將這個文件的享用權(quán)，分配給他人。在HDFS中，主控服務(wù)器NameNode實現(xiàn)了DatanodeProtocol接口，數(shù)據(jù)服務(wù)器DataNode會在主循環(huán)中，不停的調(diào)用該協(xié)議中的sendHeartbeat方法，向NameNode匯報狀況。c. 主控服務(wù)器當(dāng)然，作為整個系統(tǒng)的核心和單點，含辛茹苦的主控服務(wù)器含淚西去，整個分布式文件服務(wù)集群將徹底癱瘓罷工。對于數(shù)據(jù)服務(wù)器而言，它們會通過一些手段，迅速得知頂頭上司的更迭消息。在HDFS中，所有日志文件和鏡像文件都是本地文件，這就相當(dāng)于，把日志放在自家的保險箱中，一旦主控服務(wù)器掛了，別的后繼而上的服務(wù)器也無法拿到這些日志和鏡像，用于重振雄風(fēng)。然后，在某些時機，主控服務(wù)器自己，生成鏡像，降低日志規(guī)模。在主控服務(wù)器上，保存有此時每個數(shù)據(jù)塊的版本，一旦出現(xiàn)數(shù)據(jù)服務(wù)器上相關(guān)數(shù)據(jù)塊版本與其不一致，將會觸發(fā)相關(guān)的恢復(fù)流程。從正確性上看，此算法無疑是正確的，因為至少有一個數(shù)據(jù)服務(wù)器會發(fā)現(xiàn)此錯誤，并拒絕寫入，那么，如果寫入了的，都是正確的；從效率上看，此算法也是高效的，因為它避免了重復(fù)的傳輸和復(fù)雜的驗證，僅僅是各自刪除尾部的一些內(nèi)容即可。而且，負(fù)載均衡也是一個復(fù)雜的問題，什么是均衡，是一個很模糊的概念。Balancer類派生于Tool類，這說明，它是以一個獨立的進程存在的，可以獨立的運行和配置。此類垃圾最大的特點，就是主控服務(wù)器是生成垃圾的罪魁禍?zhǔn)祝簿褪钦f主控服務(wù)器完全了解有哪些垃圾需要處理。在HDFS的文檔中，則明確表示，在現(xiàn)行的應(yīng)用場景中，沒有需要這個需求的地方，因此，直接刪除就完了。在與數(shù)據(jù)服務(wù)器進行心跳交流的過程中，主控服務(wù)器會將它上面有哪些數(shù)據(jù)塊需要刪除，數(shù)據(jù)服務(wù)器對這些數(shù)據(jù)塊的態(tài)度是，直接物理刪除。在現(xiàn)實生活中，我們提倡垃圾分類，為了更好的理解分布式文件系統(tǒng)的垃圾收集，搞個分類也是很有必要的。具體算法，自行參見源碼。而主控服務(wù)器發(fā)起的時機，則是在占有租約的客戶端超出一定時限沒有續(xù)簽，這說明客戶端可能掛了，在臨死前可能干過不利于數(shù)據(jù)塊統(tǒng)一的事情，作為監(jiān)督者，主控服務(wù)器需要發(fā)起一場恢復(fù)運動，確保一切正確。當(dāng)數(shù)據(jù)包傳輸?shù)搅魉€的最后一級，數(shù)據(jù)服務(wù)器會對其進行驗證（想一想，為什么只在最后一級做驗證，而不是每級都做...），一旦發(fā)現(xiàn)當(dāng)前的傳輸塊簽名與在客戶端中的簽名不一致，整個數(shù)據(jù)包的寫入被視為無效，Lease Recover（租約恢復(fù)）算法被觸發(fā)。在HDFS中，為了保證數(shù)據(jù)的正確性和同一份數(shù)據(jù)的一致性，做了大量的工作。當(dāng)主控服務(wù)器犧牲的時候，運行SecondaryNameNode的服務(wù)器立刻被扶正，在其上啟動主控服務(wù)，利用其日志和鏡像，恢復(fù)文件目錄，并逐步接受各數(shù)據(jù)服務(wù)器的注冊，最終向外提供穩(wěn)定的文件服務(wù)。FSImage是Storage類的子類，如果對數(shù)據(jù)塊的講述有所印象的話，你可以回憶起來，凡事從此類派生出來的東西，都具有版本性質(zhì)，可以進行升級和回滾等等，以此，來實現(xiàn)產(chǎn)生鏡像是對原有日志和鏡像處理的復(fù)雜邏輯。一旦存有鏡像，鏡像前期所寫的日志和其他鏡像，都純屬冗余，其歷史使命已經(jīng)完成，可以報廢刪除了。它會提交本地的所有數(shù)據(jù)塊狀況給NameNode，NameNode會和本地保存的數(shù)據(jù)塊信息比較，決定什么該刪除什么該新增，并將相關(guān)結(jié)果緩存在本地對應(yīng)的數(shù)據(jù)結(jié)構(gòu)中，等待此服務(wù)器再發(fā)送sendHeartbeat消息過來的時候，依照這些數(shù)據(jù)結(jié)構(gòu)中的內(nèi)容，做出相應(yīng)的DatanodeCommand指令。一旦某數(shù)據(jù)服務(wù)器犧牲了，并且主控服務(wù)器被蒙在鼓中，主控服務(wù)器就會變相的欺騙客戶端，給它們無法連接的讀寫服務(wù)器列表，導(dǎo)致它們處處碰壁無法工作。這種事情當(dāng)然無法容忍，因此，必須有辦法解決這個問題，辦法就是：租約。服務(wù)器的錯誤恢復(fù)在分布式環(huán)境中，哪臺服務(wù)器犧牲都是常見的事情，犧牲不可怕，可怕的是你都沒有時刻準(zhǔn)備好它們會犧牲。當(dāng)一個數(shù)據(jù)塊寫滿了之后，客戶端需要向主控服務(wù)器申請追加新的數(shù)據(jù)塊。DFSOutputStream，會與序列的第一個數(shù)據(jù)服務(wù)器建立Socket連接，發(fā)送請求頭，然后等待回應(yīng)。在HDFS中，并發(fā)寫入的次序控制，是由主控服務(wù)器來把握的。當(dāng)讀取開始后，DFSInputStream會先嘗試從某個數(shù)據(jù)塊對應(yīng)的一組數(shù)據(jù)服務(wù)器中選出一個，進行連接。在數(shù)據(jù)服務(wù)器一端，DataNode類中有一個DataXceiverServer類的實例，它在一個單獨的線程等待請求，一旦接到，就啟動一個DataXceiver的線程，處理此次請求。這樣的設(shè)計，可以減少通信的次數(shù)，加快操作的執(zhí)行速度。檢查是否有相關(guān)權(quán)限；3. 在指定路徑的INode下，添加子節(jié)點；4. 寫日志。在FSNamesystem中，往往是做一些驗證和租約操作，具體的目錄結(jié)構(gòu)操作交由FSDirectory的相應(yīng)函數(shù)來操作。當(dāng)然，文件讀和寫，是有本質(zhì)區(qū)別的，尤其是在數(shù)據(jù)冗余的情況下，因此，當(dāng)成兩類操作也不足為過。服務(wù)器間協(xié)議在Hadoop的實現(xiàn)中，部署了一套RPC機制，以此來實現(xiàn)各服務(wù)間的通信協(xié)議。而FSVolume提供的接口，都基本上是和Block相關(guān)的。數(shù)據(jù)塊文件存放在數(shù)據(jù)目錄下，它有一個名為current的根目錄，然后里面有若干個數(shù)據(jù)塊文件和從dir0dir63的最多64個的子目錄，子目錄內(nèi)部結(jié)構(gòu)等同于current目錄，依次類推（更詳細(xì)的描述，參見這里）。因此沒有比較特定的業(yè)務(wù)需求，可以考慮維持此配置...）。這兩個名字，叫得都有各自的理由，是瞎子摸象各表一面。備份主控服務(wù)器SecondaryNameNode無備用的主控服務(wù)器，在身后默默的拉取著主控服務(wù)器 的日志，等待主控服務(wù)器犧牲后被扶正。但是，HDFS為了彰顯其不走尋常路的本性，其中的大量術(shù)語，都與GFS截然不同。從內(nèi)部實現(xiàn)來看，分布式的系統(tǒng)則不再和普通文件系統(tǒng)一樣負(fù)責(zé)管理本地磁盤，它的文件內(nèi)容和目錄結(jié)構(gòu)都不是存儲在本地磁盤上，而是通過網(wǎng)絡(luò)傳輸?shù)竭h(yuǎn)端系統(tǒng)上。網(wǎng)上有很多前輩們，做過Hadoop相關(guān)的源碼剖析工作，我關(guān)注最多的是這里，目前博主已經(jīng)完成了HDFS的剖析工作，Map/Reduce的剖析正火熱進行中，更新頻率之高，剖析之詳盡，都是難得一見的，所以，走過路過一定不要錯過了。分布式基礎(chǔ)學(xué)習(xí)所謂分布式，在這里，很狹義的指代以Google的三駕馬車，GFS、Map/Reduce、BigTable為框架核心的分布式存儲和計算系統(tǒng)。如此，一個看上去不錯的黃金搭檔浮出水面，Google的論文 + Hadoop的實現(xiàn)，順著論文的框架看具體的實現(xiàn)，用實現(xiàn)來進一步理解論文的邏輯，看上去至少很美。它包含這兩個方面的內(nèi)涵，從文件系統(tǒng)的客戶使用的角度來看，它就是一個標(biāo)準(zhǔn)的文件系統(tǒng)，提供了一系列API，由此進行文件或目錄的創(chuàng)建、移動、刪除，以及對文件的讀寫等操作。Hadoop的分布式文件系統(tǒng)HDFS，基本是按照Google論文中的GFS的架構(gòu)來實現(xiàn)的。傳輸塊Chunk無在每一個數(shù)據(jù)包中，都會將數(shù)據(jù)切成更小的塊，每一個塊配上一個奇偶校驗碼，這樣的塊，就是傳輸塊。存儲目錄結(jié)構(gòu)的主控服務(wù)器，在GFS中稱為Master，在HDFS中稱為NameNode。因為如果太大，容易造成熱點的堆疊，大量的操作集中在一臺數(shù)據(jù)服務(wù)器上，而如果太小的話，附加的