源自单点失效问题，也就是当NameNode不可用的时候，用什么办法可以平滑过渡？
最直接的办法是再添加一个备用的NN，这就产生了Active NameNode和Standby NameNode的设计思路。
接下来的一个问题是，如何让Standby Namenode的文件系统命名空间元数据与Active NameNode 的一致呢？
目前的解决办法有QJM方法和NFS方法。
QJM方案：添加多个Journal Node，这个数字是2F+1，通过Paxos协议保证数据的一致性，QJM最多可容忍F个JournalNode同时发生故障而系统仍然可以正常运行。
还有一个问题是，当ANN出现了故障之后，如何自动切换？
目前采用的方案是使用zookeeper实现“领导选举”。
参见下图（图片来自Linux公社）：
现在有这样一个问题：
zookeeper如何实现“领导选举”？
以下内容来自《大数据日知录：架构与算法》一书。
Zookeeper在实现领导选举时，实现方法参加如下python代码：
ZookeeperLeaderElect.py
handle = zookeeper.init("localhost:2181",my_connection_watcher,10000,0);//初始化
(data,stat) = zookeeper.get(handle,"/services/myservice/leader",True)//获取领导者节点信息
if(stat=None)
path = zookeeper.create(handle,"/services/myservice/leader",hostname:info,[ZOO_OPEN_ACL_UNSAFE],zookeeper.EPHEMERAL)
if (path==None)//说明创建leader路径失败，也就是说无法将目前节点设置为领导者节点，也就意味着在程序执行过程中间，有其他的节点的进程设置了leader节点
(data,stat) = zookeeper.get(handle,"services/myservice/leader",True)
#其他服务器是领导者
#从leader节点读取并解析领导者地址信息
else
#当前节点已经成功设置为领导者节点
else
#其他服务器是领导者
#从leader节点读取并解析领导者地址信息