這裡是大資料小白系列，這是本系列的第二篇，介紹一下HDFS中SecondaryNameNode、單點失敗（SPOF）、以及高可用（HA）等概念。

上一篇我們說到了大資料、分散式儲存，以及HDFS中的一些基本概念，為了能更好的理解後續介紹的內容，這裡先補充介紹一下NameNode到底是怎麼儲存元資料的。

首先，在啟動的時候，將磁碟中的元資料檔案讀取到記憶體，後續所有變化將被直接寫入記憶體，同時被寫入一個叫Edit Log的磁碟檔案。（如果你熟悉關係型資料庫，這個Edit Log有點像Oracle Redo Log，這是題外話）。

Q: 為什麼不把這些變化直接寫到磁碟上的元資料中，使磁碟上的元資料保持最新呢？Edit Log是不是多此一舉？

A: 這個主要是基於效能考慮，由於對Edit Log的寫是“順序寫”（追加），對元資料的寫是“隨機寫”，兩者在磁碟上表現出來的效能有相當大的差異。有興趣的同學可以搜尋學習一下磁碟相關原理哦。

上面這個方案，帶來了一些明顯的副作用。

• NameNode長期執行，不停地向Edit Log追加內容，導致它變得巨大無比。
• NameNode在重啟時，需要使用Edit Log更新元資料檔案，當Edit Log太大時，這一步驟就會耗費很長的時間。

 為了消除這些副作用，HDFS中引入了另外一個角色，SecondaryNameNode。

它定期（比如每小時）從NameNode上抓取Edit Log，使用它更新元資料檔案，並把最新的元資料檔案寫回到NameNode。

說完了SecondaryNameNode的職責之後，大家應該明白，它並不是一個“備用NameNode”，其實這是典型的命名不當，它應該被命名成“Checkpoint NameNode”才比較恰當。

接下來我們來說說HDFS中的單點失敗問題（SPOF, Single Point Of Failure），即，當NameNode掉線之後，整個HDFS叢集就變得不可用了。為解決這個問題，Hadoop 2.0中真正引入了一個“備用NameNode”。

•  對元資料的修改首先發生在NameNode，並被寫入某個“共享位置”，備用NameNode將從該位置獲取Edit Log。
• DataNode節點們同時向兩臺NameNode彙報狀態。

由於這兩點，兩臺NameNode上的元資料將一直保持同步。這將保證當NameNode掉線後，使用者可以立即切換到備用NameNode，系統將保持可用。

由於備用NameNode比較空閒（不用處理使用者請求），系統又給它安排了另外一份工作——定期使用Edit Log更新元資料檔案，也就是說它接手了SecondaryNameNode的工作。

所以，在HA環境中，我們就不再需要SecondaryNameNode了。

今天就到這裡，下一篇準備介紹JournalNode、NameNode選舉等概念，Cheers！

公眾號“程式設計師雜書館”，專注大資料，歡迎關注，每位關注者將獲贈《Spark快速大資料分析》紙質書一本！