NameNode工作机制

NameNode是HDFS的核心，NameNode存储了文件的元数据，需要根据元数据来找到文件所在的DataNode节点，NameNode中的数据肯定不能只存在内存，否则如果挂掉在启动就什么都没了，但是如果将元数据放在磁盘，随机访问就会非常慢，所以就需要进行元数据持久化。

元数据持久化

元数据存在内存，在磁盘中是有备份的元数据FsImage，但是数据量如此大的元数据，在修改时内存中的数据更新，带动FsImage数据更新，依然会导致数据更新过慢，引入Edits文件来只进行追加操作(不管元数据是添加还是修改，都是进行追加操作)，这样就可以将FsImage和Edits合并来合成内存中的元数据。

Edits文件会随着时间变得越来越大，最后合并的效率会变低，需要定期地进行两个文件的合并，这个合并操作就是由Secondary NameNode来完成的

FsImages

fsimage文件中存储了文件系统中所有目录和文件inode的序列化形式，包括了文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。其中并没有记录块存储在哪个DataNode，是在DataNode加入集群后，DataNode将自己所包含的块列表告知给NameNode

可以在NameNode的数据目录下找到fsimage文件

1 2	# hdfs oiv -p 转换格式 -i 输入(即fsimage镜像文件) -o 输出 hdfs oiv -p XML -i fsimage_0000000000000000330 -o ~/desktop/user/myself/fsimage.xml

Edits

可以在NameNode的数据目录下找到edits文件

1 2	# hdfs oev -p 转换格式 -i 输入(即fsimage镜像文件) -o 输出 hdfs oev -p XML -i edits_0000000000000000329-0000000000000000330 -o ~/desktop/user/myself/edits.xml

集群启动

在集群启动的时候先将fsimage文件加载到内存中，在执行edits中的各项操作

配置

既然是定期进行合并的，那么什么时候会触发合并呢，根据checkPoint进行配置，在hdfs-site.xml中配置

<!-- 配置Secondary NameNode多久合并一次  -->
<property>
    <name>dfs.namenode.checkpoint.period</name>
  <value>3600s</value>
</property>

<!-- 操作次数阈值，当达到该值时会触发合并  -->
<property>
    <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
</property>

<!-- 检查操作次数的时间间隔  -->
<property>
    <name>dfs.namenode.checkpoint.check.period</name>
  <value>60s</value>
</property>