13518219792
在NameNode的${dfs.namenode.name.dir}/current目录下，有这样几个文件：
在数据库系统中，log是用于记录写操作的日志的，并使用该Log进行备份、恢复数据等工作。有关写的操作的记录的，目前见过了两种：关系型数据库的log，HBase的WALs等等都是这样的写操作的日志。
HDFS也采用了类似的机制。在HDFS中，会将第一次的文件操作，看作一个事务。譬如说一个文件的创建、文件内容追加、文件移动等等写操作。从这个角度来看呢，fsp_w_picpath文件就相当于HDFS 的元数据的数据库文件了，而edit log就相当于是操作日志文件了。
Fsp_w_picpath：
每个fsp_w_picpath文件都会包括整个文件系统中所有的目录和文件inodes信息。每个inode是HDFS内部的一个代表文件、或者目录的元数据，如果inode代表一个文件，它包括：文件的备份级别、修改时间、访问时间、访问权限、block的size、所有blocks的构成等信息。如果inode代表一个目录，它包括：修改时间、权限、其它相关元数据等。
Edit log：
它在逻辑上，是一个实例（也就是说可以理解为一个对象），实际上是由多个文件组成的。每个文件都被称为一个segment，并以 edits_作为前缀，文件名后面的是事务id。
譬如上面的：edits_0000000000011403382-0000000000011403408 就代表该文件中放的是
事务Id为0000000000011403382到0000000000011403408之间的那些事务的信息。当客户端完成了一个写操作，并收到namenode的success的响应码时，Namenode才会将该事务信息写到editlog文件中。
为什么将事务信息处理后不直接写到fsp_w_picpath中？
如果这样做的话，也就是每个write操作完毕时，都去更新fsp_w_picpath文件，在一个大的文件系统中，文件就会变得很大，上GB都是有可能的，那么将是一个缓慢的过程。
先写到edit log中，怎么合并到fsp_w_picpath中呢？
解决方案是启动一个Secondary namenode。它的存在就是在内存中生成Primary NameNode的fsp_w_picpath文件。它的处理过程是这样的：
1、Secondary 告诉Primary去滚动它的in-progress edits文件，这样新来的write操作就会放到一个新的edit 文件中。同时Primary也会更新seen_txid文件。
2、Secondary 通过HTTP GET方式从Primary获取到最新的fsp_w_picpath和edits文件
3、Secondary 将fsp_w_picpath加载到内存中，并从edits文件中取出每一次事务，应用到fsp_w_picpath上，如此就产生了一个合并的新的fsp_w_picpath文件。
4、Secondary将这个新合并的fsp_w_picpath文件通过HTTP PUT发到Primary，Primary把它保存到临时.ckpt文件中。
5、Primary再把临时文件重命名，并使它可用。
同时，这也是为啥Secondary需要与Primary类似的内存配置，并且需要部署在一个单独的机器。
NameNode为什么不自己做合并，而是由Seconary NameNode来做呢？
NameNode不是不自己做，只是在启动时做。
首先，所有的写操作都会经过NameNode来处理，所以fap_w_picpath的内容，在NameNode的内存里，
肯定是有同样的一份。所以在运行期间，不需要通过合并来保证与内存一致。
其次，NameNode只是在启动时才进行合并操作。
也正由于这两点原因，所以需要由Secondary NameNode来完成了。不然NameNode运行了很长时间，比如累积了大量的editlog，而fsp_w_picpath又是NameNode启动后的那一次合并后的状态。那么NameNode重启后必然要进行长时间的合并操作。
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
