此处是本人对官方文档的理解，如有不足请指正（官方文档位置在下图）
HDFS存在的问题
NameNode单点故障，难以应用于在线场景
NameNode压力过大，且内存受限，影响系统扩展性
解决HDFS 1.0中单点故障和内存受限问题。
解决单点故障
HDFS HA：通过主备NameNode解决
如果主NameNode发生故障，则切换到备NameNode上
解决内存受限问题
HDFS Federation(联邦)
水平扩展，支持多个NameNode；
每个NameNode分管一部分目录；
所有NameNode共享所有DataNode存储资
hadoopHA架构图
对于本架构的理解
DN -> datanode namenode 汇报心跳信息和block的位置信息
NN ->(大于等于2个) 只有一个是active状态，其余的是standby状态,要想实现高可用，所有的NN中的元数据必须是一模一样的，这样在active与standby之间切换时才不会丢失数据
因为NN中的元数据是由fsimage和edits文件组成的，要保证高可用，所有的NN中的fsimage和edits必须是一模一样的
fsimage 是在hdfs格式化（-format）时，即初始化时，产生的。所有要使得所有NN中fsimage一样，需要将 -format 后的fsimage文件拷贝到其余的NN中。
edits 文件时用户进行读写操作是产生的。
因为NN中active状态的只有一个。所以只有active的NN能够产生edits文件。所以要想使所有NN都具有edits文件，active的NN就必须将edits文件共享出来
因为secondaryNameNode 一小时执行一次fsimage与edits文件的合并，且不能共享edits。所以hadoop2.X中高可用不使用secondarynamenode。
使用JN (JournalNode)进行edits的共享。JN是通过RPC协议进行共享的。（linux下文件共享 DFS）
JN(JournalNode) -> 作用是，共享edits并且合并fsimage文件。
failoverController -> 用来对NN的状态进行监控。切换NN的状态，控制NN向ZK发送心跳数据
ZK内部通过选举机制判定哪一个NN应该是Active
所以控制的检查NN状态的是FC，每个NN对应一个FC。若有5个NN则有5个FC
ZK(zookeeper) -> 是为NN做 协同服务 的，当active的NN崩溃后，通过选举算法选举一个standby的NN替换店active的NN。
