在分布式環境中，哪台伺服器
犧牲都是常見的事情，犧牲不可怕，可怕的是你都沒有時刻準備好它們會犧牲。作為一個合格的分布式系統，HDFS當然時刻準備好了前赴後繼奮勇向前。
HDFS有三類伺服器，每一類伺服器出錯了，都有相應的應急策略。。。a. 用戶端
生命最輕如鴻毛的童鞋，應該就是用戶端了。畢
竟，做為一個檔案系統的使用者，在整個檔案系統中的地位，難免有些歸於三流。而作為用戶端，大部分時候，犧牲了就犧牲了，沒人哀悼，無人同情，只有在在辛
勤寫入的時候，不幸辭世（機器掛了，或者網路斷了，諸如此類...），才會引起些恐慌。因為，此時此刻，在主控伺服器上對應的檔案，正作為
INodeFileUnderConstruction
活
著，僅僅為佔有它的那個用戶端服務者，做為一個專一的檔案，它不允許別的用戶端染指。這樣的話，一旦佔有它的用戶端服務者犧牲了，此用戶端會依然佔著茅坑
不拉屎，讓如花似玉INodeFileUnderConstruction孤孤單單守寡終身。這種事情當然無法容忍，因此，必須有辦法解決這個問題，辦法
就是：
租約
。。。租約，顧名思義，就是
當用戶端
需要佔用某檔案的時候，與主控伺服器簽訂的一個短期合約
。這個合約有一個期限，在這個期限內，用戶端可以延長合約期限，一旦超到期限，
主控伺服器會強行終止此租約，將這個檔案的享用權，分配給他人。。。在開啟或建立一個檔案，準備追加寫之前，會調用
LeaseManager
的
addLease
方
法，在指定的路徑下與此用戶端簽訂一份租約。用戶端會啟動
DFSClient.LeaseChecker
線程，定時輪
詢調用
ClientProtocol
的
renewLease
方法，續簽租約。在主
控伺服器一端，有一個
LeaseManager.Monitor
線程，始終在輪詢檢查所有租約，查看是否有到期未續的
租約。如果一切正常，該用戶端完成寫操作，會關閉檔案，停止租約，一旦有所意外，比如檔案被刪除了，用戶端犧牲了，主控伺服器都會剝奪此租約，如此，來避
免由於用戶端停機帶來的資源被長期霸佔的問題。。。b. 資料服務器
當然，會掛的不只是用戶端，海量的資料服務器是
一個更不穩定的因素。一旦某資料服務器犧牲了，並且主控伺服器被蒙在鼓中，主控伺服器就會變相的欺騙用戶端，給它們無法串連的讀寫伺服器列表，導致它們處
處碰壁無法工作。因此，為了整個系統的穩定，資料服務器必須時刻向主控伺服器彙報，保持主控伺服器對其的完全瞭解，這個機制，就是心跳訊息。在HDFS
中，主控伺服器
NameNode
實現了
DatanodeProtocol
介面，數
據伺服器
DataNode
會在主迴圈中，不停的調用該協議中的
sendHeartbeat
方
法，向NameNode彙報狀況。在此調用中，DataNode會將其整體健全狀態告知NameNode，比如：有多少可用空間、用了多大的空間，等等之
類。NameNode會記住此DataNode的健全狀態，作為新的資料區塊分配或是負載平衡的依據。當NameNode處理完成此訊息後，會將相關的指令
封裝成一個
DatanodeCommand
對象，交還給DataNode，告訴資料服務器什麼資料區塊要刪除什麼資料區塊
要新增等等之類，資料服務器以此為自己的行動依據。。。但是，sendHeartbeat並沒有提供本
地的資料區塊資訊給NameNode，那麼主控伺服器就無法知道此資料服務器應該分配什麼資料區塊應該刪除什麼資料區塊，那麼它是如何決定的呢？答案就是
DatanodeProtocol定義的另一個方法，
blockReport
。DataNode也是在主迴圈中定時調
用此方法，只是，其周期通常比調用sendHeartbeat的更長。它會提交本地的所有資料區塊狀況給NameNode，NameNode會和本地儲存的
資料區塊資訊比較，決定什麼該刪除什麼該新增，並將相關結果緩衝在本地對應的資料結構中，等待此伺服器再發送sendHeartbeat訊息過來的時候，依
照這些資料結構中的內容，做出相應的DatanodeCommand指令。blockReport方法同樣也會返回一個DatanodeCommand給
DataNode，但通常，只是為空白（只有出錯的時候不為空白），我想，增加緩衝，也許是為了確保每個指令都可以重複發送並確定被執行。。。c. 主控伺服器
當然，作為整個系統的核心和單點，含辛茹苦的主
控伺服器含淚西去，整個分布式檔案服務叢集將徹底癱瘓罷工。如何在主控伺服器犧牲後，提拔新的主控伺服器並迅速使其進入工作角色，就成了系統必須考慮的問
題。解決方案策略就是：
日誌
。。。
其實這並不是啥新鮮東西，一看就知道是從資料庫那兒偷師而來的。在主控伺服器上，所有對檔案目錄操作的關鍵步驟（具體檔案內容所處的資料服務器，是不會被
寫入日誌的，因為這些內容是動態建立的...），都會被寫入日誌。另外，主控伺服器會在某些時刻，將當下的檔案目錄完整的序列化到本地，這稱為
鏡
像
。一旦存有鏡像，鏡像前期所寫的日誌和其他鏡像，都純屬冗餘，其曆史使命已經完成，可以報廢刪除了。在主控伺服器不幸犧牲，或者是戰
略性的停機修整結束，並重新啟動後，主控伺服器會根據
最近的鏡像 + 鏡像之後的所有日誌
，重建整個檔案目錄，迅速將
服務能力恢複到犧牲前的水準。。。對於資料服務器而言，它們會通過一些手段，迅速
得知頂頭上司的更迭訊息。它們會立刻轉投新東家的名下，在新東家旗下註冊，並開始向其發送心跳訊息，這個機制，可能用分布式協同服務來實現，這裡不說也
罷。。。在HDFS的實現中，
FSEditLog
類
是整個日誌體系的核心，提供了一大堆方便的日誌寫入API，以及日誌的恢複儲存等功能。目前，它支援若干種日誌類型，都冠以OP_XXX，並提供相關
API，具體可以參見這裡
。為了保證日誌的安全性，FSEditLog提供了
EditLogFileOutputStream
類
作為寫入的承載類，它會同時開若干個本地檔案，然後依次寫入，防止日誌的損壞導致不可估量的後果。在FSEditLog上面，有一個
FSImage
類，
隱藏檔鏡像並調用FSEditLog對外提供相關的日誌功能。FSImage是Storage類的子類，如果對資料區塊的講述有所印象的話，你可以回憶起
來，凡事從此類派生出來的東西，都具有版本性質，可以進行升級和復原等等，以此，來實現產生鏡像是對原有日誌和鏡像處理的複雜邏輯。。。目前，在HDFS的日誌系統中，有些地方與
GFS的描述有所不同。在HDFS中，所有記錄檔和鏡像檔案都是本地檔案，這就相當於，把日誌放在自家的保險箱中，一旦主控伺服器掛了，別的後繼而上的
伺服器也無法拿到這些日誌和鏡像，用於重振雄風。因此，在HDFS中，運行著一個
SecondaryNameNode
服
務器，它做為主控伺服器的替補，隱忍厚積薄發為篡位做好準備，其中，核心內容就是：
定期下載並處理日誌和鏡像
。
SecondaryNameNode看上去像用戶端一樣，與NameNode之間，走著
NamenodeProtocol
協
議。它會不停的查看主控伺服器上面累計日誌的大小，當達到閾值後，調用
doCheckpoint
函數，此函數的主要步
驟包括：
- 首先是調用startCheckpoint
做
一些本地的初始化工作；
- 然後調用rollEditLog
，
將NameNode上此時操作的記錄檔從edit
切到edit.new
上來，這
個操作瞬間完成，上層寫日誌的函數完全感覺不到差別；
- 接著，調用downloadCheckpointFiles
，
將主控伺服器上的鏡像檔案和記錄檔都下載到此候補主控伺服器上來；
- 並調用doMerge
，
開啟鏡像和日誌，將日誌產生新的鏡像，儲存覆蓋；
- 下一步，調用putFSImage
把
新的鏡像上傳回NameNode；
- 再調用rollFsImage
，
將鏡像換成新的，在日誌從edit.new改名為edit；
- 最後，調用endCheckpoint
做
收尾工作。
整個演算法涉及到NameNode和
SecondaryNameNode兩個伺服器，最終結果是NameNode和SecondaryNameNode都依照
演算法進行前
的
日誌產生了鏡像。而兩個伺服器上記錄檔的內容，前者是整個
演算法進行期間
所寫的日誌，後者始終不會有任何日誌。當主控
伺服器犧牲的時候，運行SecondaryNameNode的伺服器立刻被扶正，在其上啟動主控服務，利用其日誌和鏡像，恢複檔案目錄，並逐步接受各資料
伺服器的註冊，最終向外提供穩定的檔案服務。。。同樣的事情，GFS採用的可能是另外一個策略，
就是在寫日誌的時候，並不局限在本地，而是同時書寫
部落格
，即在若干個遠程伺服器上產生同樣的日誌。然後，在某些時
機，主控伺服器自己，產生鏡像，降低日誌規模。當主控伺服器犧牲，可以在擁有部落格的伺服器上啟動主控服務，升級成為主控伺服器。。。GFS與HDFS的策略相比較，前者是化整為
零，後者則是批量處理，通常我們認為，批量處理的平均效率更高一些，且相對而言，可能實現起來容易一些，但是，由於有間歇期，會導致日誌的丟失，從而無法
100%的將備份主控伺服器的狀態與主控伺服器完全同步。。。
