大數(shù)據(jù) | HDFS 如何實現(xiàn)故障自動轉(zhuǎn)移
早期文章
為什么需要自動故障轉(zhuǎn)移
? ? ? ? 在 HDFS 2.x 集群的 HA 模式下通常會有兩個 NameNode 用來進(jìn)行記錄元數(shù)據(jù)，其中一個是主節(jié)點（Active），另外一個是備節(jié)點（Standby）。主備之間的數(shù)據(jù)同步通過 JournalNode 節(jié)點來充當(dāng)中介，從而完成了主備節(jié)點之間數(shù)據(jù)的最終一致性。
?? ? ? ?當(dāng) NameNode 的主節(jié)點宕機(jī)后，通過命令可以切換到它的備節(jié)點成為主節(jié)點，使用命令進(jìn)行切換需要人工的參與，雖然這樣可以解決?HDFS?高可用的問題，但是這樣的切換還是比較繁瑣的。因此需要在 Active 節(jié)點發(fā)生故障的時候進(jìn)行自動地切換到 Standby 節(jié)點，從而完成故障自動轉(zhuǎn)移。
? ? ? ? 為了實現(xiàn)故障的自動轉(zhuǎn)移，HDFS 引入了 ZooKeeper 和 ZKFC。
故障自動轉(zhuǎn)移
? ? ? ??HDFS 為了實現(xiàn)故障自動轉(zhuǎn)移功能添加了兩個組件，分別是 ZooKeeper 集群
?和 ZKFailoverController 進(jìn)程。其中，ZKFailoverController 簡稱為 ZKFC。
? ? ? ? ZooKeeper 在故障自動轉(zhuǎn)移中的作用大體有兩個，第一個是 NameNode 的選“主”，第二個是監(jiān)聽故障的發(fā)生。
? ? ? ? ZKFC 在故障自動轉(zhuǎn)移中的作用大體也是兩個，第一個是在 ZooKeeper 中用于爭搶鎖完成選“主”，第二個是當(dāng) Active 節(jié)點發(fā)生故障時，用于完成故障的自動切換。
HDFS HA 故障自動轉(zhuǎn)移架構(gòu)圖
? ? ? ??來看一下 HDFS HA 故障自動轉(zhuǎn)移架構(gòu)圖。在圖中，非藍(lán)色部分是 HDFS 的 HA 模式，藍(lán)色部分則完成了故障自動轉(zhuǎn)移的功能，即當(dāng) Active 節(jié)點發(fā)生故障時，會自動切換 Standby 節(jié)點為 Active 節(jié)點。
? ? ? ? 本圖和上篇文章 《HDFS 在 HA 模式集群下 JournalNode 節(jié)點的作用》?的圖稍微有所差別。首先，ZooKeeper 集群的節(jié)點是單數(shù)節(jié)點，上篇文章的圖中 ZooKeeper 畫了四臺；第二，ZKFC 和 NameNode 在同一臺主機(jī)中，因此把它們框在了一起。
NameNode 如何選主
? ? ? ??在了解 ZKFC 如何完成自動切換前，需要了解 NameNode 如何進(jìn)行選主。NameNode 節(jié)點的選主是一件比較容易的事情，ZKFC 會在 ZooKeeper 下創(chuàng)建一個”臨時節(jié)點“，哪個 ZKFC 先創(chuàng)建了該節(jié)點，那么創(chuàng)建了該節(jié)點的 ZKFC 對應(yīng)的 NameNode 就是主節(jié)點（Active）。沒有創(chuàng)建成功的 ZKFC 對應(yīng)的 NameNode 即為備節(jié)點（Standby）。NameNode 選主是爭搶制，無需選舉，誰搶上就是誰的。
ZKFC 完成故障自動轉(zhuǎn)移
? ? ? ??兩個 ZKFC 通過爭搶在 ZooKeeper 中創(chuàng)建鎖，創(chuàng)建成功的即為”主“，那么沒有創(chuàng)建的成功的 ZKFC 會創(chuàng)建一個監(jiān)聽事件。當(dāng)”主“發(fā)生宕機(jī)或斷網(wǎng)后，鎖會被自動刪除，此時 ZooKeeper 會通知備節(jié)點的 ZKFC。當(dāng)備節(jié)點的 ZKFC 接收該通知時，就會開始做故障自動轉(zhuǎn)移的工作。
? ? ? ? 一般主發(fā)生故障會有幾種情況。首先，主 NameNode 服務(wù)掛了，這時它對應(yīng)的 ZKFC 會主動刪除 ZooKeeper 中的鎖；第二種情況是，主 NameNode 對應(yīng)的 ZKFC 掛了（但是 NameNode 健在），那么它在 ZooKeeper 中創(chuàng)建的臨時節(jié)點也會被刪除；還有第三種情況是，主 NameNode 所在的主機(jī)斷網(wǎng)了。
? ? ? ? 上面說了產(chǎn)生故障的可能性，那么來說下一故障轉(zhuǎn)移的大體流程。首先來說，主 NameNode 服務(wù)掛掉后的故障轉(zhuǎn)移，大致流程如下：
? ? ? ? 首先，主節(jié)點對應(yīng)的 ZKFC 發(fā)現(xiàn)主 NameNode 服務(wù)掛掉了，那么它會主動去 ZooKeeper 中刪除鎖。然后，備節(jié)點對應(yīng)的 ZKFC 收到通知后會去創(chuàng)建鎖；接著，備節(jié)點的 ZKFC 會去看一下主節(jié)點的 NameNode，此時發(fā)現(xiàn)主節(jié)點的 NameNode 已經(jīng)不活著了；最后，備節(jié)點的 ZKFC 會把備節(jié)點的 NameNode 提升為主節(jié)點。
? ? ? ??第二種情況是，主節(jié)點的 NameNode 服務(wù)還存在，但是它對應(yīng)的 ZFKC 進(jìn)程掛掉了。當(dāng) ZKFC 進(jìn)程掛掉后，它在 ZooKeeper 中創(chuàng)建的臨時節(jié)點會自動刪除。然后，備節(jié)點對應(yīng)的 ZKFC 收到通知還是去會爭搶鎖；接著，它會去看看主節(jié)點的 NameNode，發(fā)現(xiàn)主節(jié)點的 NameNode 還在，此時它會讓主節(jié)點的 NameNode 降級成為從節(jié)點；最后，會把原來的備節(jié)點的 NameNode 提升為主節(jié)點。
總結(jié)
? ? ? ? 通過三篇文章，整列了關(guān)于 HDFS 的幾個技術(shù)點，分別是 HDFS 元數(shù)據(jù)的持久化，HDFS 主備節(jié)點之間如何完成數(shù)據(jù)一致性，還有本篇文章整理的 ZKFC 完成故障自動轉(zhuǎn)移。三篇文章均沒有涉及任何配置、命令和原理。只是講其中的思想、流程等進(jìn)行了介紹。
? ? ? ? 通過幾篇文章，聯(lián)系自己已有的一些技術(shù)知識會發(fā)現(xiàn)，很多技術(shù)都是相通的。比如 HDFS 元數(shù)據(jù)的持久化是通過 FsImage 和 EditsLog 來完成的，而 FsImage 和 EditsLog 的原理和 Redis 的 RDB 和 AOF 又非常相似。而 JournalNode 完成數(shù)據(jù)的最終一致性，其實對于其他技術(shù)中主備完成數(shù)據(jù)一致性來說也是相似的。
? ? ? ? 很多 API 的使用，基本可能是學(xué)一個會一個，而原理則可能是一通百通。把知識的相關(guān)性不斷的聯(lián)系起來，可能解決問題，學(xué)習(xí)新知識就會越來越快了。
公眾號內(nèi)回復(fù)?【mongo】 下載 SpringBoot 整合操作 MongoDB 的文檔。
? ? ? ? 之前整理的關(guān)于 Redis 的文章：
Redis | Redis Pub/Sub相關(guān)命令
Redis | 基礎(chǔ)數(shù)據(jù)類型應(yīng)用場景