Hadoop中NameNode与SecondaryNameNode的运行机制解析

　　思考：nameNode中元数据的是存在哪里的呢？

　　有两个可能，一个是存在磁盘中，另一个可能是存在内存中。如果存在磁盘中的话，效率比较低  ，因为需要经常的随机访问还要给出对应的响应到客户。如果吃存到内存中，一旦断点元数据就会丢失，集群则无法正常的工作。因此我们可以把两者结合，在磁盘中备份元数据  FSImage.

　　新问题来了。如果内存中数据更新的时候同时在磁盘中备份数据，会导致效率降低，如果不更新就导致数据一致性。一旦NameNode断点会导致数据丢失。

　　HDFS有一个特性是修改比较慢的特征，此时产生一个新的文件  Edits文件，只追加信息。当元数据有变动的时候，修改内存中元数据并追加到Edits中。如果NameNode节点断电会合并FSImage和Edits文件，如果数据过大断电的时候合并依然由NameNode进行，就会浪费时间，所以会定期的对两个文件进行合并，且这个操作交由SecondaryNameNode来操作。

 第一 阶段：NameNode 启动
    （1）第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果不是第一次启
         动，直接加载编辑日志和镜像文件到内存。
    （2）客户端对元数据进行增删改的请求。
    （3）NameNode 记录操作日志，更新滚动日志。
    （4）NameNode 在内存中对元数据进行增删改

第二 阶段：Secondary NameNode 工作
    （1）Secondary NameNode 询问 NameNode 是否需要 CheckPoint。直接带回 NameNode
        是否检查结果。
    （2）Secondary NameNode 请求执行 CheckPoint。
    （3）NameNode 滚动正在写的 Edits 日志。
    （4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
    （5）Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
    （6）生成新的镜像文件 fsimage.chkpoint。
    （7）拷贝 fsimage.chkpoint 到 NameNode。
    （8）NameNode 将 fsimage.chkpoint 重新命名成 fsimage