源代码分析（三七）

Secondary NameNode的成员变量很少，主要的有：

  privateCheckpointStorage checkpointImage;
Secondary NameNode使用的Storage

  privateNamenodeProtocol namenode;
和NameNode通信的接口

  privateHttpServer infoServer;
传输文件用的HTTP服务器

main方法是Secondary NameNode的入口，它最终启动线程，执行SecondaryNameNode的run。启动前的对SecondaryNameNode的构造过程也很简单，主要是创建和NameNode通信的接口和启动HTTP服务器。

SecondaryNameNode的run方法每隔一段时间执行doCheckpoint()，从NameNode的主要工作都在这一个方法里。这个方法，总的来说，会从NameNode上取下FSImage和日志，然后再本地合并，再上传回NameNode。这个过程结束后，从NameNode上保持了NameNode上持久化信息的一个备份，同时，NameNode上已经完成合并到FSImage的日志可以抛弃，一箭双雕。

具体的的流程是：

1：调用startCheckpoint，为接下来的工作准备空间。startCheckpoint会在内部做一系列的检查，然后调用CheckpointStorage的startCheckpoint方法，创建目录。

2：调用namenode的rollEditLog方法，开始一次新的检查点过程。调用会返回一个CheckpointSignature（检查点签名），在上传合并完的FSImage时，会使用这个签名。

Namenode的rollEditLog方法最终调用的是FSImage的同名方法，前面提到过这个方法，作用是关闭往edits上写的日志，打开日志到edits.new。明显，在Secondary NameNode下载fsimage和日志的时候，对命名空间的修改，将保持在edits.new的日志中。

注意，如果FSImage这个时候的状态（看下面的状态机，前面出现过一次）不是出于CheckpointStates.ROLLED_EDITS，将抛异常结束这个过程。

3：通过downloadCheckpointFiles下载fsimage和日志，并设置本地检查点状态为CheckpointStates.UPLOAD_DONE。

4：合并日志的内容到fsimage中。过程很简单，CheckpointStorage利用继承自FSImage的loadFSImage加载fsimage，loadFSEdits应用日志，然后通过saveFSImage保存。很明显，现在保存在硬盘上的fsimage是合并日志的内容以后的文件。

5：使用putFSImage上传合并日志后的fsimage（让NameNode通过HTTP到从NameNode取文件）。这个过程中，NameNode会：

调用NameNode的FSImage.validateCheckpointUpload，检查现在的状态；
利用HTTP，从Secondary NameNode获取新的fsimage；
更新结束后设置新状态。

6：调用NameNode的rollFsImage，最终调用FSImage的rollFsImage方法，前面我们已经分析过了。

7：调用本地endCheckpoint方法，结束一次doCheckpoint流程。

其实前面在分析FSImage的时候，我们在不了解SecondaryNameNode的情况下，分析了很多和Checkpoint相关的方法，现在我们终于可以有一个比较统一的了解了，下面给出NameNode和Secondary NameNode的存储系统在这个流程中的状态转移图，方便大家理解。

图中右侧的状态转移图：

文件系统上的目录的变化（三六中出现）：