源代码分析（三六）

转战进入Secondary NameNode，前面的分析我们有事也把它称为从NameNode，从NameNode在HDFS里是个小配角。

跟Secondary NameNode有关系的类不是很多，如下图：

源代码分析（三六）%20-%20-%20JavaEye技术网站.mht!http://caibinbupt.javaeye.com/upload/attachment/65342/54fdafd5-7f2e-30e3-aca0-add0afff1c4a.jpg">
 

首先要讨论的是NameNode和Secondary NameNode间的通信。NameNode上实现了接口NamenodeProtocol（如下图），就是用于NameNode和Secondary NameNode间的命令通信。

NameNode和Secondary NameNode间数据的通信，使用的是HTTP协议，HTTP的容器用的是jetty，TransferFsImage是文件传输的辅助类。

GetImageServlet的doGet方法目前支持取FSImage(getimage)，取日志(getedit)和存FSImage(putimage)。例如：

http://localhost:50070/getimage?getimage

可以获取FSImage。

http://localhost:50070/getimage?getedit

可以获取日志文件。

保存FSImage需要更多的参数，它的流程很好玩，SecondaryNameNode发送一个HTTP请求到NameNode，启动NameNode上一个HTTP客户端到SecondaryNameNode上去下载FSImage，下载需要的一些信息，都放在从NameNode的HTTP请求中。

我们先来考察Secondary NameNode持久化保存的信息：

[hadoop@localhostnamesecondary]$ ls –R
.:
current  image  in_use.lock previous.checkpoint

./current:
edits  fsimage  fstime VERSION

./image:
fsimage

./previous.checkpoint:
edits  fsimage  fstime VERSION

in_use.lock的用法和前面NameNode，DataNode的是一样的。对比NameNode保存的信息，我们可以发现Secondary NameNode上保存多了一个previous.checkpoint。CheckpointStorage就是应用于Secondary NameNode的存储类，它继承自FSImage，只添加了很少的方法。

previous.checkpoint目录保存了上一个checkpoint的信息（current里的永远是最新的），临时目录用于创建新checkpoint，成功后，老的checkpoint保存在previous.checkpoint目录中。状态图如下（基类FSImage用的是黑色）：

至于上面目录下文件的内容，和FSImage是一样的。

CheckpointStorage除了上面图中的startCheckpoint和endCheckpoint方法（上图给出了正常流程），还有：

    voidrecoverCreate(Collection<File> dataDirs,

                      Collection<File> editsDirs) throwsIOException

和FSImage.coverTransitionRead类似，用于分析现有目录，创建目录（如果不存在）并从可能的错误中恢复。

    privatevoid doMerge(CheckpointSignature sig) throws IOException

doMerge被类SecondaryNameNode的同名方法调用，我们后面再分析。