开发者学堂课程【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工作机制，如图所示。
二、具体操作步骤：
（一）NameNode（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
