這里是大數據小白系列，這是本系列的第三篇，介紹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快速大數據分析》紙質書一本

總結

以上是生活随笔為你收集整理的大数据小白系列——HDFS(3)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。