企业是如何解决 HDFS 单点问题的？

前言

在早期 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 去下载，信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们下期见~~~

>资源获取 获取 Flink 面试题，Spark 面试题，程序员必备软件，hive 面试题，Hadoop 面试题，Docker 面试题，简历模板等资源请去

>GitHub 自行下载 https://github.com/lhh2002/Framework-Of-BigData

>Gitee 自行下载 https://gitee.com/liheyhey/dashboard/projects