2019独角兽企业重金招聘Python工程师标准>>> 
对于hdfs中的namenode，是非常重要的一环。今天闲来，深入了解一下namenode和 secondary namenode机制和原理。
- NAMENODE职责：
负责客户端请求的响应
元数据的管理（查询，修改）
2. 元数据管理
namenode对数据的管理采用了三种存储形式：
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件（可通过日志运算出元数据）
3. 元数据存储机制
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户 端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功 后，相应的元数据会更新到内存meta.data中。
可以通过hdfs的一个工具来查看edits中的信息
bin/hdfs oev -i edits -o edits.xml
bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml4. 元数据的checkpoint
每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）。
checkpoint 的详细过程
详细解读这个过程：
1.如果客户端涉及到元数据的更新（读数据不算更新，比如更改文件的名称、路径等、删除文件，增删改操作）。注意客户端不能更改文件内容，顶多可以追加操作。会有操作日志到NameNode的记录日志中。
2.随着元数据的操作记录日志增多，secondary NameNode 也会定期的去请求NameNode是否需要checkpoint.
3.如果得到应答，namenode会滚动当前的日志edits.inprogress,将当前记录的edits和namenode中的fsimage下载到secondary namenode中。
4.secondary namenode会将其两者加载到内存合并，dump成新的image文件，重新上传到namenode中，重命名为新的fsimage.
5.这里要注意的是，checkpoint时，会把正在写的edits滚动一下，然后将fsimage和日志下载到secondary namenode机器，只有第一次hdfs初始化时才下载fsimage,这时的文件操作没有那么大的数据量。以后只负责下载日志文件，合并旧的fsimage。
6. 这样两者之间的元数据镜像差距始终保持在范围很小的差距。
我通过实验，在NameNode工作时，将日志和fsimage都删除，依然都能工作。
结论：NameNode工作的时候元数据的查询都是找内存。并不会找fsimage和edits。
那这两个数据都是用来干嘛？
答案：主要是用来持久化，如果说NameNode宕机，内存中没有元数据，那hdfs重新启动的时候。数据就从fsimage和edits这两个文件中加载。
namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。
checkpoint出发条件：
1.设置默认时间
2.edits中记录数据