NameNode和Secondary NameNode工作机制

1 工作机制

第一阶段：NameNode启动

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

第二阶段：Secondary NameNode工作

1. Secondary NameNode询问NameNode是否需要checkpoint，直接带回NameNode的询问结果
2. Secondary NameNode请求执行checkpoint
3. NameNode滚动正在写的Edits日志
4. 将滚动前的Edits日志和Fsimage文件都由到Secondary NameNode
5. Secondary NameNode加载Edits日志和镜像文件到内存，执行合并
6. 生成新的镜像文件fsimage.chkpoint
7. 拷贝fsimage.chkpoint到NameNode
8. NameNode将fsimage.chkpoint重新命名成fsimage

工作机制详解：

• Fsimage：NameNode内存中元数据序列化后形成的文件
• Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）

NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息，然后NameNode会在内存中执行元数据的增删改的操作。

由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。Secondary NameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。

Secondary NameNode首先会询问NameNode是否需要checkpoint（触发Checkpoint需要满足两个条件中的任意一个：定时时间和Edits中数据写满了），直接带回检查结果。Secondary NameNode执行Checkpoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其它未合并的Edits和Fsimage会拷贝到Secondary NameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，NameNode将fsimage.chkpoint重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可有，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。

2 Fsimage和Edits概念

NameNode被格式化之后，将在/opt/module/hadoop-2.x.x/data/tmp/dfs/name/current目录中产生如下文件

fsimage_000000000000000

fsimage_000000000000000.md5

seen_txid

VERSION

1. Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和idnode的序列化信息
2. Edtis日志：存储HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到Edits文件中
3. seen_txid文件保存的是一个数字，就是最后一个edits_的数据
4. 每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并