一、NameNode高可用整體架構(gòu)
架構(gòu)：
NameNode組建包括：
（1）Active NameNode——主NameNode，可以對外提供讀寫服務(wù)
（2）standby NameNode——備NameNode
（3）ZKFailoverController——主備切換控制器，獨立進程運行，可及時檢測到NameNode的健康狀況，不依賴與手動切換
（4）Zookeeper集群——為主備切換控制器提供主備選舉支持
（5）共享存儲系統(tǒng)——是實現(xiàn)NameNode高可用性的關(guān)鍵，對元數(shù)據(jù)（并不是所有）進行共享和存儲，而主NameNode和備NameNode通過其實現(xiàn)數(shù)據(jù)的同步。
（6）DataNode——同時向主NameNode和備NameNode 上報數(shù)據(jù)塊的位置信息
二、NameNode的主備切換
流程圖：
NameNode主備切換主要是由zkfc完成，主要由HealthMonitor、ZKFailoverController和ActiveStandbyElector三個組件協(xié)同完成。
zkfc作為獨立進程啟動，啟動時創(chuàng)建HealthMonitor和ActiveStandbyElector兩個主要內(nèi)部組件。
HealthMonitor主要負(fù)責(zé)檢測NameNode 的健康狀態(tài)，如果檢查到NameNode的健康狀態(tài)發(fā)生改變，它會回調(diào)ZKFailoverController的相應(yīng)方法進行自動的主備選舉。
ActiveStandbyElector主要負(fù)責(zé)完成自動的主備選舉，它內(nèi)部封裝了Zookeeper的處理邏輯，一旦主備選舉完成，就會回調(diào)ZKFailoverController的相應(yīng)方法進行主備切換。
ZKFC監(jiān)控Active NameNode健康狀況，一旦發(fā)生問題，利用Zookeeper 集群進行選舉。再決定NameNode到底是Active NameNode還是standby NameNode。
三、NameNode的共享存儲
NameNode 在執(zhí)行 HDFS 客戶端提交的創(chuàng)建文件或者移動文件這樣的寫操作的時候，會首先把這些操作記錄在 EditLog 文件之中，然后再更新內(nèi)存中的文件系統(tǒng)鏡像。內(nèi)存中的文件系統(tǒng)鏡像用于 NameNode 向客戶端提供讀服務(wù)，而 EditLog 僅僅只是在數(shù)據(jù)恢復(fù)的時候起作用。
NameNode 會定期對內(nèi)存中的文件系統(tǒng)鏡像進行 checkpoint 操作，在磁盤上生成 FSImage 文件。在 NameNode 啟動的時候會進行數(shù)據(jù)恢復(fù)，首先把 FSImage 文件加載到內(nèi)存中形成文件系統(tǒng)鏡像，然后再把 EditLog 之中 FsImage 的結(jié)束事務(wù) id 之后的 EditLog 回放到這個文件系統(tǒng)鏡像上。
基于 QJM 的共享存儲系統(tǒng)主要用于保存 EditLog，并不保存 FSImage 文件。FSImage 文件還是在 NameNode 的本地磁盤上。每次 NameNode 寫 EditLog 的時候，除了向本地磁盤寫入 EditLog 之外，也會并行地向 JournalNode 集群之中的每一個 JournalNode 發(fā)送寫請求，只要大多數(shù) (majority) 的 JournalNode 節(jié)點返回成功就認(rèn)為向 JournalNode 集群寫入 EditLog 成功。如果有 2N+1 臺 JournalNode，那么根據(jù)大多數(shù)的原則，最多可以容忍有 N 臺 JournalNode 節(jié)點掛掉。
當(dāng)處于 Active 狀態(tài)的 NameNode 調(diào)用 FSEditLog 類的 logSync 方法來提交 EditLog 的時候，會通過 JouranlSet 同時向本地磁盤目錄和 JournalNode 集群上的共享存儲目錄寫入 EditLog。寫入 JournalNode 集群是通過并行調(diào)用每一個 JournalNode 的 QJournalProtocol RPC 接口的 journal 方法實現(xiàn)的，如果對大多數(shù) JournalNode 的 journal 方法調(diào)用成功，那么就認(rèn)為提交 EditLog 成功，否則 NameNode 就會認(rèn)為這次提交 EditLog 失敗。
當(dāng) NameNode 進入 Standby 狀態(tài)之后，會啟動一個 EditLogTailer 線程。這個線程會定期調(diào)用 EditLogTailer 類的 doTailEdits 方法從 JournalNode 集群上同步 EditLog，然后把同步的 EditLog 回放到內(nèi)存之中的文件系雖然 Active NameNode 向 JournalNode 集群提交 EditLog 是同步的，但 Standby NameNode 采用的是定時從 JournalNode 集群上同步 EditLog 的方式，那么 Standby NameNode 內(nèi)存中文件系統(tǒng)鏡像有很大的可能是落后于 Active NameNode 的，所以 Standby NameNode 在轉(zhuǎn)換為 Active NameNode 的時候需要把落后的 EditLog 補上來。
處于 Standby 狀態(tài)的 NameNode 轉(zhuǎn)換為 Active 狀態(tài)的時候，有可能上一個 Active NameNode 發(fā)生了異常退出，那么 JournalNode 集群中各個 JournalNode 上的 EditLog 就可能會處于不一致的狀態(tài)，所以首先要做的事情就是讓 JournalNode 集群中各個節(jié)點上的 EditLog 恢復(fù)為一致。另外，當(dāng)前處于 Standby 狀態(tài)的 NameNode 的內(nèi)存中的文件系統(tǒng)鏡像有很大的可能是落后于舊的 Active NameNode 的，所以在 JournalNode 集群中各個節(jié)點上的 EditLog 達(dá)成一致之后，接下來要做的事情就是從 JournalNode 集群上補齊落后的 EditLog。只有在這兩步完成之后，當(dāng)前新的 Active NameNode 才能安全地對外提供服務(wù)。
