在HDFS相关的守护进程中，有NameNode进程、DataNode进程、SecondaryNameNode进程等。NameNode和DataNode职责比较明确，我们都知道是做什么的，那么SecondaryNameNode的作用是什么呢?为什么SecondayNameNode要和NameNode部署在不同的节点上呢?有人说SecondaryNameNode是NameNode的备份，这种说法正确吗?我们来理解一下SecondaryNameNode是什么，主要是做什么工作的。

　　在正式的介绍SecondaryNameNode之前，我们先来认识两种文件: fsimage 和 eidts。我们都知道NameNode有一个作用就是维护HDFS分布式文件系统的目录树结构。在HDFS上有什么目录、每一个目录下又有什么文件等等，这些信息是需要维护的。

　　NameNode在内存中维护文件系统的目录树结构，而这样的目录树结构随着HDFS的重启不会丢失，也就说明NameNode会将其序列化到本地磁盘上，以文件的形式保存下来。这个文件就是fsimage文件。我们可以在NameNode所在的节点发现这个文件。

　　那么，是不是我们每次对HDFS进行操作的时候，NameNode都会将内存中记录的HDFS的目录树结构序列化下来呢?显然不应该是这样的，因为如果你的文件系统中的文件比较多、比较复杂，在内存中维护的数据量也会比较庞大，我们假设1G。那么如果每当对目录树结构产生了修改之后，都需要将内存中的数据序列化到磁盘上的话，就产生大量的磁盘IO。而且在序列化期间，如果NameNode宕机的话，会出现数据丢失的情况。

　　因此，NameNode并不会实时的将每一次的变更都序列化到本地磁盘上。而是会周期性的进行序列化，一般来说一个小时序列化一次，生成fsimage文件。那么在这一个小时的时间之内，如果产生了新的文件结构变更怎么办?这个时候，NameNode会将新的操作以edit log的形式保存在文件中，edit log中并不会保存全部的目录结构，而只是记录了某一次的变更操作。

　　在NameNode启动的时候，首先加载本地磁盘上的fsimage文件，将一个完整的目录结构读取到内存中。然后再依次读取每一个edit log中的记录，在内存中进行推荐，对目录树结构进行推演。这样就可以得到上次关机的时候完整的目录树结构。

　　那么，SecondaryNameNode是干什么的呢?上面提到了，NameNode会周期性的对内存中的目录结构进行序列化，生成fsimage文件。其实这个工作是由SecondaryNameNode来完成的。SecondaryNameNode会辅助NameNode进行fsimage和edit log的合并工作，减小editlog的大小，从而能够缩减下一次启动NameNode的时间。两个文件的合并周期，称之为检查点机制(checkpoint)，是可以通过hdfs-default.xml配置文件进行修改的：

<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600</value>
<description>两次检查点间隔的秒数，默认是1个小时</description>
</property>
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>txid执行的次数达到100w次，也执行checkpoint</description>
</property>
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60</value>
<description>60秒一检查txid的执行次数</description>
</property>

　　1. SecondaryNamenode请求Namenode停止使用正在编辑的editlog文件，Namenode会创建新的editlog文件，同时更新seed_txid文件。

　　2. SecondaryNamenode通过HTTP协议获取Namenode上的fsimage和editlog文件。

　　3. SecondaryNamenode将fsimage读进内存当中，并逐步分析editlog文件里的数据，进行合并操作，然后写入新文件fsimage_x.ckpt文件中。

　　4. SecondaryNamenode将新文件fsimage_x.ckpt通过HTTP协议发送回Namenode。

　　5. Namenode再进行更名操作。