为了解决HDFS1.0的设计存在的单点故障问题，HDFS2.0开始采用了HA（High Availability高可用）架构。
在HDFS HA中，设置两个NameNode，一个处于Active状态对外进行服务，另一个处于Standby状态，随时待命成为Active。因为Standby NN 是 Active NN的“热备份” ，所以Active的状态信息必须实时同步到Standby中。 状态的同步，我们一般借助JN
(JournalNode),它能使得Standby监听Active，一旦发现Active有新的写入，就立刻读取数据并加载到自己的内存里，从而使Active和Standby的状态完全同步。
当我们的Active挂掉时，ZKFC，一个单独地进程，会通过RPC协议将我们另一台Standby自动切换成Active，从而保证集群中一直存在一个Active对外服务。
DN（DataNode）会不定时地向两个NN发送心跳，告知健康状态与Block信息。
角色：
ACTIVE NN: 操作记录写到自己的editlog
同时将信息写入JN集群中
接收DN的心跳和块报告
STANDBY NN: 同时接收JN集群的日志，显示读取执行log操作(重演)，以保证两个NN的状态一致
接收DN的心跳和块报告
JounalNode: 用于active standby nn节点的同步数据
一般部署2n+1
ZKFC: 单独的进程，ZKFC是一个Zookeeper的客户端
监控NN健康状态
向zk集群定期发送心跳，使得自己可以被选举；
当自己被zk选举为active的时候，zkfc进程通过RPC协议调用使NN节点的状态变为active，
对外提供实时服务，是无感知的。
Zookeeper集群作用主要有：
通过节点竞争锁的，选举哪个节点做Active，哪个节点做Standby。
为保证选举机制，zookeeper集群也是2n+1台。
20台节点: 5台
20~100台节点: 7/9/11台
>100台节点: 11台
但是: 不是说zk节点越多越好 ，因为越多的zk节点，选举的时候会很慢，大大的影响了对外服务的效率。
几百台节点, zk部署的机器就它一个进程