FsImage和Editslog分别是什么 ？
- Editslog ：保存了所有对hdfs中文件的操作信息
- FsImage：是内存元数据在本地磁盘的映射，用于维护管理文件系统树，即元数据(metadata)
在hdfs中主要是通过两个数据结构FsImage和EditsLog来实现metadata的更新。在某次启动hdfs时，会从FSImage文件中读取当前HDFS文件的metadata，之后对HDFS的操作步骤都会记录到edit log文件中。
metadata信息就应该由FSImage文件和edit log文件组成。fsimage中存储的信息就相当于整个hdfs在某一时刻的一个快照。
FsImage文件和EditsLog文件可以通过ID来互相关联。如果是非HA集群的话，这两个数据文件保存在dfs.namenode.name.dir设置的路径下，会保存FsImage文件和EditsLog文件，如果是HA集群的话，EditsLog文件保存在参数dfs.journalnode.edits.dir设置的路径下，即edits文件由qjournal集群管理。
fsimage和editlog文件
在上图中edit log文件以edits_开头，后面跟一个txid范围段，并且多个edit log之间首尾相连，正在使用的edit log名字edits_inprogress_txid。该路径下还会保存两个fsimage文件（{
dfs.namenode.num.checkpoints.retained
}在namenode上保存的fsimage的数目，超出的会被删除。默认保存2个），文件格式为fsimage_txid。上图中可以看出fsimage文件已经加载到了最新的一个edit log文件，仅仅只有inprogress状态的edit log未被加载。
在启动HDFS时，只需要读入fsimage_0000000000000008927以及edits_inprogress_0000000000000008928就可以还原出当前hdfs的最新状况。
（FsImageid总是比editslogid小）
那么这两个文件是如何合并的呢？这就引入了checkpoint机制
checkpoint机制：
因为文件合并过程需要消耗io和cpu所以需要将这个过程独立出来，在Hadoop1.x中是由Secondnamenode来完成，且Secondnamenode必须启动在单独的一个节点最好不要和namenode在同一个节点，这样会增加namenode节点的负担，而且维护时也比较方便。同样在HA集群中这个合并的过程是由Standbynamenode完成的。
1.合并的过程：过程类似于TCP协议的关闭过程
- 首先Standbynamenode进行判断是否达到checkpoint的条件（是否距离上次合并过了1小时或者事务条数是否达到100万条）
- 当达到checkpoint条件后，Standbynamenode会将qjournal集群中的edits和本地fsImage文件合并生成一个文件fsimage_ckpt_txid（此时的txid是与合并的editslog_txid的txid值相同），同时Standbynamenode还会生成一个MD5文件，并将fsimage_ckpt_txid文件重命名为fsimage_txid
- 向Activenamenode发送http请求（请求中包含了Standbynamenode的域名，端口以及新fsimage_txid的txid），询问是否进行获取
- Activenamenode获取到请求后，会返回一个http请求来向Standbynamenode获取新的fsimage_txid，并保存为fsimage.ckpt_txid，生成一个MD5，最后再改名为fsimage_txid。合并成功。
2.合并的时机：
什么时候进行checkpoint呢？这由两个参数dfs.namenode.checkpoint.preiod(默认值是3600，即1小时)和dfs.namenode.checkpoint.txns(默认值是1000000)来决定
（1） 距离上次checkpoint的
时间间隔
{
dfs.namenode.checkpoint.period
}
（2） Edits中的
事务条数
达到{
dfs.namenode.checkpoint.txns
}限制，
事物条数又由{
dfs.namenode.checkpoint.check.period
(默认值是60）}决
定，checkpoint节点隔60秒就会去统计一次hdfs的操作次数。
如有错误，希望大家指出，万分感谢！