Hadoop源代码分析（三六）

nescafeboy1

　　转战进入Secondary NameNode，前面的分析我们有事也把它称为从NameNode，从NameNode在HDFS里是个小配角。
　　跟Secondary NameNode有关系的类不是很多，如下图：
　　

 
　　首先要讨论的是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需要更多的参数，它的流程很好玩，Secondary NameNode发送一个HTTP请求到NameNode，启动NameNode上一个HTTP客户端到Secondary NameNode上去下载FSImage，下载需要的一些信息，都放在从NameNode的HTTP请求中。
　　我们先来考察Secondary NameNode持久化保存的信息：
[hadoop@localhost namesecondary]$ 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方法（上图给出了正常流程），还有：

    void recoverCreate(Collection<File> dataDirs,

                       Collection<File> editsDirs) throws IOException

　　和FSImage.coverTransitionRead类似，用于分析现有目录，创建目录（如果不存在）并从可能的错误中恢复。
　　    private void doMerge(CheckpointSignature sig) throws IOException
　　doMerge被类SecondaryNameNode的同名方法调用，我们后面再分析。