hdfs单点故障和内存受限问题

1. 解决hdfs单点故障问题的方法

HDFS HA：通过主备NameNode解决 一个集群中只能有一个NameNode处于工作状态 当主NameNode发送故障 则切换到备NameNode上（NameNode的两大功能：接收客户端的读写请求 存储元数据 ）

整个集群在输入hdfs namenode -format时 产生元数据 此时hdfs集群还没有启动 主NameNode会格式化产生（初始化）fsimage 而备NameNode则不会产生fsimage 因为如果两个都格式化产生fsimage的话 由于环境和系统时间的不同fsimage一定会不同 从而导致主NameNode在发生故障时备NameNode无法接管 正确的情况应该是在主NameNode格式化后备NameNode把主NameNode的fsimage拷贝过来 以保证初始化时两个NameNode的元数据一模一样 为以后的成功接管提供条件

edits文件在客户端对hdfs进行操作时产生 当有元数据的增删改查日志产生时 它会直接保存到一个内部的集群中 称之为JournalNode 一般会有2个或3个以上的副本 同时fsimage文件和edits文件的合并工作也由JournalNode完成 主NameNode（Active）挂了之后 备NameNode（Standby）接管后 会同样会把日志保存到JournalNode中

JournalNode在合并fsimage和edits文件以更新fsimage文件时 需要同时合并两个NameNode的fsimage 从而保证瞬间实现接管

DataNode在启动的时候 会向两个NameNode汇报block的位置信息 从而保证瞬间实现接管

备NameNode与主NameNode相比 仅仅少了接收客户端读写请求的工作 其他的一模一样 因为内存中的元数据来源于hdfs在启动时从磁盘读入的fsimage 初始化时 两台NameNode上的fsimage是一模一样的 因此在启动之初 两个NameNode加载到内存中的元数据是一模一样的 DataNode在启动的时候 向两个NameNode汇报block的位置信息以元数据的形式存在于两个NameNode的内存中 因此两个NameNode中的元数据是又是一模一样的 edits文件保存在共享的集群中 和fsimage合并后也是一样的

备NameNode在接管主NameNode时 只要正常接收客户端的读写请求功能即可 因此可以实现瞬间接管

接管的先决条件是 两台NameNode上的元数据一模一样

2. 解决hdfs内存受限问题的方法

为什么会出现内存受限：当数据量太大时 NameNode中元数据占用的空间也会很大 内存太小 不足以保存

国内大部分公司的解决方法：加集群 即根据业务的不同 使用多个集群分别存储 同一个业务 如果数据量过大 也可以根据时间的不同 使用多个集群分别存储

官方提供的解决方法：HDFS Federation（联邦） 

它可以水平扩展 支持多个NameNode 每个NameNode分管一部分目录 所有DataNode共享所有NameNode的资源