這裡是大資料小白系列，這是本系列的第三篇，介紹HDFS中NameNode選舉，JournalNode等概念。

上一期我們說到了為解決NameNode(下稱NN)單點失敗問題，HDFS中使用了雙NN的機制，一個Active NN，一個Standby NN。

現實常常是，解決一個問題的同時，免不了又引入了另外的問題。

誰來擔任Active，誰來擔任Standby？

兩個NN誰也說服不了誰，這個時候需要引入一個外部角色：一個Zookeeper(下稱ZK)叢集。

ZK也是個很有趣的東西，大資料小白系列後續會專門介紹。

這裡，ZK叢集扮演了類似裁判的角色，如果兩個NN同時申請成為Active，由ZK決定誰將獲勝。

兩臺NN機器上都分別存在一個ZKCF(Zookeeper Failover Controller)程序，該程序相當於ZK的一個客戶端。

ZKFC定期檢查NN程序的狀態，如狀態正常，並且目前沒有其他NN在持有ZK叢集上的鎖，則加入選舉，並且申請鎖。(注：所謂的鎖，實際上是ZK叢集上的一種特殊目錄)

若ZKFC檢查NN程序不正常，則退出選舉，並放棄ZK上的鎖(如持有)。

Q：如果不是NN程序死了，而是整個NN機器掉電了呢？

A：當叢集與ZKFC程序的連線斷開超過一定時間，鎖將自動過期，以便其他NN可以申請重新選舉。

Q：如果Active、Standby都死了呢？

A：不好意思，那就死透了。

上一期提到的另外一個內容，Active NN負責將Edit Log寫入某個“共享儲存”，而Standby NN負責從該位置讀取以保持同步。

最簡單的，可以使用NFS(Network File System)來擔任共享儲存。

但是NFS本身成為了單點失敗，即，如果NFS系統壞了，導致Edit Log無法讀寫，整個HDFS系統也就無法工作。

因此，HDFS推薦使用的是專為Edit Log高可用性所設計的“JournalNode(下稱JN))叢集”。

NN通過QJM(Quorum Journal Manager)程序將Edit Log寫入某JN節點，該JN節點需要將資料寫入其他JN節點，直到資料被寫入叢集中的“多數節點”，本次操作才算成功。

例如，JN叢集中共有3個節點，需要寫入到其中2個節點，即所謂的“多數”(majority)。

通常，JN叢集總是包含奇數個節點，至於為什麼，我準備在介紹ZK的時候再來說明，因為二者比較類似。

需要注意，雖然QJM的工作機制類似於ZK，但本身並沒有用到ZK，同時它也比ZK來的輕量級，它可以跑在叢集現有的機器上，而不需要單獨為它準備機器。

好了，這期就先到這，下期我們將介紹現實世界中的HDFS叢集，以及Federation等概念。Cheers!

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