[[379511]]

前言

在早期Hadoop剛出來的時候是沒有解決HDFS單點問題的，這就意味著當NameNode的服務器宕機了就會導致整個集群癱瘓，這是非常危險的于是在Hadoop不斷的更新下提出了Hadoop HA來解決NameNode單點問題，接下來我們就來聊一聊。

解決HDFS單點問題解決方案 解決HDFS點單問題其實可以部署兩個NameNode，但是真正對外服務只有一個，部署兩個NameNode那他們之間的元數據信息是不是需要共享元數據信息呀，不然當其中一個NameNode掛掉了元數據信息沒有同步不就會有問題。

根據appche提出的解決方案目前有三種解決方案如下

方案一、目錄共享

目錄共享是在appche社區中提出但是現在沒有引用，目錄共享也是一個單點問題，如果當目錄共享掛掉了是不是也會導致HDFS掛掉。所以就被一些企業拋棄了。

方案二、使用JournalNode方案

我們使用JN來保存元數據信息就不會造成單點問題，JN也是一個集群，我們一般部署JN一般會選擇基數例如3,5,7,9等。JN有一個政策只要存活的節點大于二分之一就是一個正常的服務。

注意：我們不要為了解決NameNode的單點問題選擇的的組件也是單點問題，這個根本還是沒有解決。

JN中的信息都是一樣的，那為什么也是其中的一個NameNode就是寫數據其中一個就是讀取數據那?

其實NameNode也是有角色之分的寫的為action讀為standby,在高可用的架構中只有一個NameNode真正對外服務， 用戶也只會對action的NameNode進行打交道，舉個理解:假設我們在工作中有2個領導(平級的)我們去請假其中一個領導同意其中一個領導不同意那這個假到底修還是不修那?這不就亂套了嗎?也就是在高可用架構中同一時間只有一個說的算。

方案三、使用zookeeper方案

其實企業中也有好多使用zookeeper來帶代替了。我們來想一想JN解決了什么問題，不是就數據的一致性和單點故障我們在想想zookeepr是不是也有，于是企業中就把zookeeper的源碼改了改就使用了這個方案。

總體架構

以上的解決方案是不是可以解決了NameNode單點問題，假設在凌晨的時候action的NameNode掛掉了是不是要進行切換我們是不是需要人工去切換。是不是切換不及時就到導致整個集群不可用。接下來我實現自動切換。

兩個NameNode啟動成功后都會去zookeeper注冊自己zookeeper中會有一把鎖那個NameNode注冊成功了就是action當其他的NameNode在去注冊是發現已經被注冊了就變成了standby。

每個NameNode都部署了ZKFC 來監控NameNode的情況當action的NameNode發生故障時ActionZKF通過zookeeper刪除臨時的zNode (釋放鎖)StandBy狀態下的ZKF訂閱了這個臨時的zNode的變換，若zNode消失，StandBy狀態的ZKFC立刻通過standby NameNode。StandByNameNode遠程登錄actionNameNode執行kill-9 actionNameNode。StandByNameNode通知StandByZkfc去zookeeper上注冊zNode，注冊成功轉換為action狀態。這樣就實現了自己轉換

小結

上述給大家講解了幾種解決HDFS單點故障的問題，不知道大家吸收有多少，如果有不會的可以在下方留言或著私信我 我來給你解答。下期會分享NameNode內存受限該怎么解決。 我在這里為大家提供大數據的資料(企業面試題，簡歷模板等)需要的朋友可以去下面GitHub去下載，信自己，努力和汗水總會能得到回報的。

本文轉載自微信公眾號「大數據老哥」，可以通過以下二維碼關注。轉載本文請聯系大數據老哥公眾號。