在複雜紛繁的分布式環境中，
我們堅定的相信，萬事皆有可能。哪怕各個伺服器都舒舒服服的活著，也可能有各種各樣的情況導致網路傳輸中的資料丟失或者錯誤。並且在Distributed File System中，同
一份檔案的資料，是存在大量冗餘備份的，系統必須要維護所有的資料區塊內容完全同步，否則，一人一言，不同用戶端讀同一個檔案讀出不同資料，使用者非得瘋了不
可。。。在HDFS中，為了保證資料的正確性和同一份數
據的一致性，做了大量的工作。首先，每一個資料區塊，都有一個版本標識，在
Block
類中，用一個長整型的數
generationStamp
來
表示版本資訊（Block類是所有表示資料區塊的資料結構的基類），一旦資料區塊上的資料有所變化，此版本號碼將
向前增加
。
在主控伺服器上，儲存有此時每個資料區塊的版本，一旦出現資料服務器上相關資料區塊版本與其不一致，將會觸發相關的恢複流程。這樣的機制保證了各個資料服務器
器上的資料區塊，在基本大方向上都是一致的。但是，由於網路的複雜性，簡單的版本資訊無法保證具體內容的一致性（因為此版本資訊與內容無關，可能會出現版本
相同，但內容不同的狀況）。因此，為了保證資料內容上的一致，必須要依照內容，作出
簽名
。。。當用戶端向資料服務器追加寫入資料包時，每一個
資料包的資料，都會切分成
512位元組
大小的段，作為簽名驗證的基本單位，在HDFS中，把這個資料區段稱為
Chunk，
即傳輸塊
（注意，在GFS中，Chunk表達的是資料區塊...）。在每一個資料包中，都包含若干個傳輸塊以及每一個傳輸塊的簽名，當
下，這個簽名是根據Java SDK提供的
CRC
演算法算得的，其實就是一個同位。當資料包傳輸到流水線的
最
後一級
，資料服務器會對其進行驗證（想一想，為什麼只在最後一級做驗證，而不是每級都做...），一旦發現當前的傳輸塊簽名與在用戶端
中的簽名不一致，整個資料包的寫入被視為無效，
Lease Recover（租約恢複）演算法
被觸發。。。從基本原理上看，這個演算法很簡單，就是
取
所有資料服務器上此資料區塊的最小長度當作正確內容的長度，將其他資料服務器上此資料區塊超出此長度的部分切除
。從正確性上看，此演算法無疑
是正確的，因為至少有一個資料服務器會發現此錯誤，並拒絕寫入，那麼，如果寫入了的，都是正確的；從效率上看，此演算法也是高效的，因為它避免了重複的傳輸
和複雜的驗證，僅僅是各自刪除尾部的一些內容即可。但從具體實現上來看，此演算法稍微有些繞，因為，為了降低本已不堪重負的主控伺服器的負擔，此演算法不是由
主控伺服器這個大腦發起的，而是通過選舉一個資料服務器作為
Primary
，由Primary發起，通過調用與其他各
資料服務器間的
InterDatanodeProtocol
協議，最終完成的。具體的演算法流程，參見
LeaseManager
類
上面的注釋。需要說明的是此演算法的觸發時機和發起者。此演算法可以由
用戶端
或者是
主控伺服器
發
起，當用戶端在寫入一個資料包失敗後，會發起租約恢複。因為，一次寫入失敗，不論是何種原因，很有可能就會導致流水線上有的伺服器寫了，有的沒寫，從而造
成不統一。而主控伺服器發起的時機，則是在佔有租約的用戶端超出一定時限沒有續簽，這說明用戶端可能掛了，在臨死前可能幹過不利於資料區塊統一的事情，作為
監督者，主控伺服器需要發起一場恢複運動，確保一切正確。。。
