前言
在早期Hadoop刚出来的时候是没有解决HDFS单点问题的，这就意味着当NaMEnode的服务器宕机了就会导致整个集群瘫痪，这是非常危险的于是在Hadoop不断的更新下提出了Hadoop HA来解决NaMEnode单点问题，接下来我们就来聊一聊。
解决HDFS单点问题解决方案 解决HDFS点单问题其实可以部署两个NaMEnode，但是真正对外服务只有一个，部署两个NaMEnode那他们之间的元数据信息是不是需要共享元数据信息呀，不然当其中一个NaMEnode挂掉了元数据信息没有同步不就会有问题。
根据提出的解决方案目前有三种解决方案如下
方案一、目录共享
目录共享是在社区中提出但是现在没有引用，目录共享也是一个单点问题，如果当目录共享挂掉了是不是也会导致HDFS挂掉。所以就被一些企业抛弃了。
方案二、使用JouRnalNode方案
我们使用JN来保存元数据信息就不会造成单点问题，JN也是一个集群，我们一般部署JN一般会选择基数例如3,5,7,9等。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去下载，信自己，努力和汗水总会能得到回报的。