HDFS2.x中Fimage文件和Edit.log文件的作用

在HDFS中，每一个文件块。都会有一条元数据用来唯一标识这个文件块的存在。而Fimage和edit.log这两个文件就是用来保存，处理这些元数据信息的文件。

Fimage和edit.log文件

元数据的特点：频繁操作，量大

因为元数据需要频繁操作这个特点，所以要将元数据（MetaData）存放到内存中，以便于高速访问。但是由于内存（RAM随机存储器）的断电数据丢失的特性，因此在硬盘中需要有一份元数据的镜像因此有了FSImage这个文件。但是，由于元数据量巨大，对硬盘中的文件进行编辑的时候较为困难编辑（这里感觉用修改更好，但是已经写了编辑就用编辑吧。）因此催生出了EditLog这个文件。这个文件是NameNode将所有对元数据的修改的操作全部存放到了这个文件里面。并且，由于这个文件存放的是操作过程。因此只需要追加就可以满足我们备份元数据的需求（只需要在后面将修改过程，变为实质的内容持久化到FSImage中就可以了）。

前面我们提到将元数据备份到硬盘中需要有一个EditLog文件的帮助，才可以完成。因此就需要一个时机来合并这两个文件，以保证元数据的一致性。在Hadoop中是通过两个维度来控制的

时间维度：看设定的时间是不是已经到了，如果时间到达设定的时间片段之后就可以对两个文件合并。

空间维度：看EditLog文件的大小是不是超过了设定的大小范围，如果超过了大小范围。那么也要对两个文件进行合并，以保证数据的完整性和一致性。

前面我们说到，由于元数据要访问快速，并且元数据的数据量大，并且FSImage和EditLog这两个文件的体量都是相当巨大的。因此合并两个文件的任务是非常巨大，由此引入了SecondaryNameNode，它的主要任务和工作就是帮助NameNode合并FSImage和EditLog这两个文件。当时间或者文件的空间大小触发时候，开始执行文件合并任务。让NameNode高效快速的去做他的元数据管理工作。

NameNode和SecondaryNameNode的工作机制

NameNode和SecondaryNameNode工作流程图

NameNode加载编辑日志文件和镜像文件到内存中-->元数据的增删改请求-->将增删改操作记录到Edit.log文件中-->修改内存中的数据-->SecondaryNameNode向NameNode发出请求是不是合并Edit.log文件和FSImage文件（时间到达，或者Edit.log文件足够大）-->当NameNode允许的时候。将两个文件加载到内存中合并文件，并拷贝到相应的位置。