Hadoop二次开发必备，Hadoop源码分析（十四）

转战进入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需要更多的参数，它的流程很好玩，SecondaryNameNode发送一个HTTP请求到NameNode，启动NameNode上一个HTTP客户端到SecondaryNameNode上去下载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方法（上图给出了正常流程），还有：    voidrecoverCreate(Collection<File> dataDirs,                      Collection<File> editsDirs) throwsIOException和FSImage.coverTransitionRead类似，用于分析现有目录，创建目录（如果不存在）并从可能的错误中恢复。    private voiddoMerge(CheckpointSignature sig) throwsIOExceptiondoMerge被类SecondaryNameNode的同名方法调用，我们后面再分析。

---------------------------------------------------------------------------------------------------------------------------------------------------


Secondary NameNode的成员变量很少，主要的有：
  private CheckpointStorage checkpointImage;
Secondary NameNode使用的Storage
  private NamenodeProtocol namenode;
和NameNode通信的接口
  private HttpServer 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的时候，我们在不了解Secondary NameNode的情况下，分析了很多和Checkpoint相关的方法，现在我们终于可以有一个比较统一的了解了，下面给出NameNode和Secondary NameNode的存储系统在这个流程中的状态转移图，方便大家理解。





图中右侧的状态转移图：




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

下一篇

Hadoop二次开发必备，Hadoop源码分析（十五）

上一篇

Hadoop二次开发必备，Hadoop源码分析（十三）