Fsimage 作用：镜像文件
Edits wtet：编辑日志
（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息（id、类型、目录、所属用户、用户权限、时间戳……）。
（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字
（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

为了解决元数据备份的问题，HDFS采用了edits+FsImage的策略，edits文件保存了客户端的更新操作，Fsimage保存了元数据的具体内容。HDFS在运行时将客户端的操作响应在内容中的元数据上，同时将所有的更新操作写入edits文件，避免了直接对FsImage进行操作造成效率降低
HDFS为了解决edits不断追加写入过大的问题，采用了edits与FsImage合并的策略。即edits文件不是一直在原文件中进行写入的，而是在一定时间或者条件后，就把该时间段内客户端的更新操作同步到FsImage文件中，来更新FsImage文件的内容。这样，新的edits文件就可以只记录合并之后的更新操作，从而减小了edits文件的大小。
HDFS通过引入SecondaryNameNode来实现上述过程，利用了一台独立的机器资源来处理合并流程。所谓edits与FsImage的合并，其实就是在SecondaryNamenode内存中，将edits中记录一条一条的在fsiamge中执行，来更新Fsiamge的内容。同时，可以知道，SecondaryNameNode获取到的FsImage不是最新的，因为在它从NameNode下载edits和FsImage文件的时候，新的更新操作已经写到新的edits文件里去了（比如这里的edits_inprogress_002）。而这些更新在SecondaryNamenode是没有同步到的。
edits和FsImage利用了文件命名格式来标识各自的最新文件。如fsiamge和edits文件图中所示，edits文件以edits_开头，后面跟一个txid范围端，并且多个edit log之间首尾相连，正在使用的edits文件名字为edits_inprogress_txid。该路径下还会保存两个FsImage文件（dfs.namenode.num.checkpoints.retained在namenode上保存的fsimage个数的默认配置，超过的被删除，默认保存两个）。文件格式为fsimage_txid，txid与edits中的txid对应，表示该fsimage加载的是哪一个edits。比如从图中可以看出，此时的fsimage已经加载到尾数为1545的edits文件内容