开发者学堂课程【Hadoop 分布式文件系统 HDFS：NN和2NN工作机制】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/93/detail/1456

NN和2NN工作机制

​

内容介绍：

一、前期准备

二、具体操作步骤

 

一、前期准备：

思考: NameNode 中的元数据是存储在哪里的?

首先，我们做个假设，如果存储在 NameNode 节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。

但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage,就会导致效率过低，但如果不更新，就会发生一"致性问题，一.旦 NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。

每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到 Edits 中。这样，一旦 NameNode节点断电，可以通过 FsImage 和 Edits 的合并，合成元数据。

但是，如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一"旦断电，恢复元数据需要的时间过长。

因此，需要定期进行 FsImage 和 Edits 的合并，如果这个操作由NameNode节点完成，又会效率过低。

因此,引入一个新的节点 SecondaryNamenode,专门用于FsImage和 Edits 的合并。

NN和2NN工作机制，如图所示。

二、具体操作步骤：

​（一）​​N​ameNode（nn）

1.  client是客户端，NameNode一启动，加载编辑日志(edits_inprogress_001)和镜像文件(fsimage)到内存。

2.   fsimage 存储元数据，edits_inprogress-001是元数据操作面积，内存128g，每个Block 占元数据150byte.

3.  元数据的增删改请求/user/atguigu/ss.avi。

4.  记录操作日志，更新滚动日志。

5.  内存数据增删改。

（二）Seconfary NameNode.(2nn)

1.  请求是否需要 checkpoint。

CheckPoint 触发条件:

1 )定时时间。

2 ) Edits 中的数据满了。

2.  请求执行 CheckPoint。

3.  滚动执行edits_001，edits_inprogress_002。

4.  拷贝到2nn.

5.  Fsimage，edits_001加载到内存并合并。

6.  生成新的 Fsimage，改名fsimage.chkpoint

7.  拷贝到 nn

8.  重新命名成 Fsimage