Hadoop2.0中HDFS高可用性的实现原理

在Hadoop1.0中，NameNode在HDFS集群中存在单点故障问题，每一个集群中只存在一个NameNode，如果NameNode所在的机器出现故障，那么整个集群就无法利用，直到NameNode重启或在另一台主机上启动NameNode守护进程。因此，有两个因素影响了HDFS的高可用性：
（1）、在不可预知的情况下，如果NameNode所在的机器崩溃了，整个集群将无法利用，直到NameNode被重启。
（2）、在可预知的情况下，比如NameNode所在的机器硬件或软件需要升级，将导致整个集群宕机。

在Hadoop2.0中，通过在一个集群中运行两个NameNode（active NN，standbyNN），解决了上面的两个问题：如果active NN所在机器崩溃或需要维护，可以快速的启动standby NN来恢复正常。

在典型的HA集群中，通常有两台不同的机器作为NameNode，不过只有一台处于Active状态，另一台则处于Standby状态，Active NN负责集群中所有客户端的操作，而Standby NN用于备用。

为了让Standby NN和Active NN保持同步（元数据保持一致），它们都将会和JournalNodes守护进程通信。当Active NN执行任何有关命名空间的修改的 操作时，它需要持久化到一半以上的JournalNodes上（通过edits log持久化存储），而Standby NN负责观察edits log的变化，它能够从JournalNodes中读取edits的信息，并更新自己的命名空间。一旦Active NN出现故障，Standby NN将会保证从JournalNodes读取了全部的edits（保证和Active NN拥有完全同步的命名空间状态），并切换为Active状态。

namenode想要做HA，一个namenode挂掉以后，另一个namenode想要快速接替，就必须同步数据。 数据由两部分产生，一部分来自客户端，另一部分来自
DataNode，DataNode的数据由datanode同时向两台namenode发送数据，同时做心跳连接，是一致保持一致的。另外一部分原数据（即客户端原数据）
想要保持一致只需借助一个组件（journalnode），当客户端发送来数据的时候，由组件记录数据，并异步同步到另一台namenode上即可。

1）namenode总共两种数据，动态的和静态的，由客户端产生的动态数据和由data产生的静态数据

2）datanode同时向两个namenode发送心跳，同步block的位置信息

3）journalnode是HDFS自己带的一个角色。每个journalnode是一个进程，journalnode使用集群可避免单点故障，journalnode技术类似于linux系统的NFS（挂载network FileSystem）。

4）同步客户端源数据的原理：假设有三台journalnode，客户端发送来数据，会向三台journalnode上面写数据，当有过半的journalnode写成功就默认写成功了（过半机制）。之后会把数据同步到
另一台namenode上，这样两台namenode上的数据就会保持一致了，一台挂掉，另一台可以迅速的接替。

5）完成这个已经是HA，一个namenode是active，一个namenode是standy，只是还不是自动的，当其中一个namenode挂掉后，要手动的把另一个启动起来变成active。一般企业都会使用zookeeper
集群做成自动的