SecondNamenode名字看起来很象是第二个NameNode，要么与NameNode一样同时对外提供服务，要么相当于NameNode的HA。真正的了解了SecondNameNode以后，才发现事实并不是这样的。
        下面这段是Hadoop对SecondNameNode的准确定义：
        *The Secondary NameNode is a helper to the primary NameNode.
        *The Secondary is responsible for supporting periodic checkopoints
        *of the HDFS metadata. The current design allows only one Secondary
        *Namenode per HDFS cluster.
        *
        *The Secondary NameNode is a daemon that periodically wakes
        *up(determined by the schedule specified in the configuration)，
        *triggers a periodic checkpoint and then goes back to sleep.
        *The Secondary NameNode uses the ClientProtocol to talk to the
        *primary NameNode.
        SecondNameNode是对主NameNode的一个补充，它会周期的执行对HDFS元数据的检查点。
        当前的设计仅仅允许每个HDFS只有单个SecondNameNode结点。
        SecondNameNode是有一个后台的进程，会定期的被唤醒(唤醒的周期依赖相关配置)执行检查点任务，然后继续休眠。
        它使用ClientProtocol协议与主NameNode通信。
        
        １，检查点到底是什么用的呢？
        先抛开SecondNameNode不说，先介绍下NameNode中与检查点相关的两个文件，以及他们之间的关系。
        fsimage文件与edits文件是NameNode结点上的核心文件
        NameNode中仅仅存储目录树信息，而关于BLOCK的位置信息则是从各个DataNode上传到NameNode上的。
        NameNode的目录树信息就是物理的存储在fsimage这个文件中的，当NameNode启动的时候会首先读取fsimage这个文件，将目录树信息装载到内存中。
        而edits存储的是日志信息，在NameNode启动后所有对目录结构的增加，删除，修改等操作都会记录到edits文件中，并不会同步的记录在 fsimage中。而当NameNode结点关闭的时候，也不会将fsimage与edits文件进行合并，这个合并的过程实际上是发生在 NameNode启动的过程中。也就是说，当NameNode启动的时候，首先装载fsimage文件，然后在应用edits文件，最后还会将最新的目录 树信息到新的fsimage文件中，然后启用新的edits文件。整个流程是没有问题的，但有个小瑕疵，就是如果NameNode在启动后发生的改变过 多，会导致edit文件变得非常大，大得程度与NameNode的更新频率有关系。那么在下一次NameNode启动的过程中，读取了fsimage文件 后，会应用这个无比大的edits文件，导致启动时间变长，并且不可能控，可能需要启动几个小时也说不定。
        NameNode的edits文件过大的问题，也就是SecondeNameNode要解决的主要问题。
        SecondeNameNode会按照一定规则被唤醒，然后进行fsimage文件与edits文件的合并，防止edits文件过大，导致NameNode启动时间过长。
        ２.检查点被唤醒的文件？
        以前的文章里面曾经写过相关内容，这里在回顾一下。控制检查点的参数有两个，分别是：
        fs.checkpoint.period:单位秒，默认值3600，检查点的间隔时间，当距离上次检查点执行超过该时间后启动检查点
        fs.checkpoint.size:单位字节，默认值67108864，当edits文件超过该大小后，启动检查点
        上面的两个条件是或的关系，只要满足任何一个条件，检查点即被唤醒
        ３.检查点执行的过程？
        a.初始化检查点
        b.通过NameNode启用新的edits文件
        c.从NameNode下载fsimage和edits文件
        d.调用loadFSImage装载fsimage
        e.调用loadFSEdits应用edits日志
        f.保存合并后的目录树信息到新的image文件中
        g.将新产生的image上传到NameNode中，替换原来的image文件
        h.结束检查点
        ４.SecondNameNode最好与NameNode部署到不同的服务器
        应用在merge的过程中，SecondNameNode对内存的需求与NameNode是相同的，所以对于那些大型的生产系统中，如果将两者部署到同台 服务器上，在内存上会出现瓶颈。所以最好将他们分别部署到不同的服务器。修改hadoop配置文件的master文件。
        ５.关于SecondNameNode的思考
        其实检查点的执行过程最好在NameNode结点搞定，也就说能有个任务定期的将NameNode的内存结果刷新到fsimage中，而不是仅仅在 NameNode启动的时候才进行一次合并。如果可以实现定期的对NameNode执行检查点，那么SecondNameNode完全没有存在的必要了。 或者在SecondNameNode方面实现增量的刷新，每次不需要将fsimage整个装载到内存中，而仅仅将增量刷新就OK了。
        不过这样会让系统变得复杂一些，可以参考oracle中的检查点的处理，还是有些复杂的。
        简单就是美？！！