对于HDFS,纱线的每个角色都是一个进程,
比如HDFS:神经网络/SNN DN老大是NN
纱:RM/NM老大是RM
对于上面,都会存在单点故障的问题,假如老大神经网络或者RM挂了,那么就不能提供对外服务了,会导致整个集群都不能使用。
大数据几乎所有的组建都是主从架构(主从)。比如HDFS的读写请求都是先经过NN节点。(但是hbase的读写请求不是经过老大的主人)。
HDFS:由神经网络/SNN DN组成,SNN每小时会做一次检查点的操作,如果NN挂了,只能恢复到上次检查点的那一刻,不能实时。现在如果把SNN的角色再提升一个等级,让它和NN一样,如果NN挂了,SNN能立即切换过来就好了。
HDFS HA架构有两个神经网络节点,一个是积极活跃状态,一个是备用准备状态,活跃NameNode对外提供服务,比如处理来自客户端的RPC请求,而备用NameNode则不对外提供服务,仅同步活跃NameNode的状态,对活跃NameNode进行实时备份,以便能够在它失败时快速进行切换。
<强>
HDFS高可用性(HA)
假定:
NN1活跃ip1
NN2备用ip2
用命名空间来解决。命名空间不是进程。比如:命名空间的名称为: ruozeclusterg7
脚本里可以这样写:HDFS dfs - ls HDFS://ruozeclusterg7/
当代码执行到这一行时,它会去core-site.xml, hdfs-site。xml里面查找。在这两个配置文件里面，配置了ruozeclusterg7命名空间下挂了NN1和NN2。当它找到NN1，它会尝试着连接第一个机器NN1，如果发现它不是active状态，它会尝试着连接第二个机器NN2，如果发现NN1是active状态，就直接用了。
hadoop001:ZK NN ZKFC JN DN
hadoop002:ZK NN ZKFC JN DN
hadoop003:ZK JN DN
NN节点有fsimage、editlog(读和写请求的记录)两个文件,有专门的进程去管理的，这个进程是JN（journalnode）日志节点，要保证NN1和NN2能实时同步，需要JN这个角色。
如果NN1挂了，需要把NN2从standby状态切换到active状态，那它是怎么切换的呢？需要ZKFC。
ZKFC: 是单独的进程，它监控NN健康状态，向zk集群定期发送心跳，使得自己可以被选举；当自己被zk选举为active的时候，zkfc进程通过RPC协议调用使NN节点的状态变为active。对外提供实时服务，是无感知的。
所以在上面，需要在三台机器上都部署一下zookeeper，作为一个集群，ZK集群，是用于做选举的。选举谁来做老大（active），谁做standby。集群中ZK的个数是2n+1，这样能投票保证最后有一个胜出。
生产上zookeeper部署的个数经验：如果集群中有20台节点，那么可以在5台上部署zk。如果总共有七八台，也部署5台zk。如果总共有20~100台节点，可以部署7台/9台/11台 zk。如果大于100台，可以部署11台zk。如果有很多，比如上万台那看情况可以多部署几台。但是，不是说zk节点越多越好。因为做投票选举动作的时候，投票谁做active，谁做standby是需要时间的，时间间隔太长会影响对外服务，对外服务会很慢，对于即时性 的服务来说，这是不允许的。
他们的集群有很多台，比如几百台几千台，zk部署的机器上就它一个进程，不部署其它进程了。在这里是学习或者机器很少，所以一台机器上部署多个进程。如果几百台节点，任务很重，如果部署zk的机器上有其它进程，那么它会消耗很多机器上的资源（无外乎cpu、内存、文件数、进程数），这都会影响zk响应的速度，所以一般都会把它独立出来。但是如果机器是256G内存，但是zk只用到32G，那其他的就浪费了，那么买机器的时候，可以单独给zk买32G内存的机器就可以了。
zk是最底层的，如果zk太繁忙，就可能导致standby状态不能切换到active状态，这个时候机器可能就会夯住。所以当机器夯住，standby不能切换到active的时候，有可能就是zk出问题了。
关于HA 架构的官方文档https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
Architecture
In a typical HA cluster, two or more separate machines are configured as NameNodes. 在任何时候,一个namenode处于活跃的状态,和其他人都处于备用状态。活跃的NameNode负责集群中所有客户端操作,而备用只是作为工人,保持足够的状态在必要时提供一个快速的故障转移。
