NameNode中元数据存储问题及工作机制

一. NameNode中的元数据存在哪？

答：如果存储在 NameNode 节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的Fsimage。
这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新 Fsimage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦 NameNode 节点断电，就会产生数据丢失。
因此，引入Edits文件（不进行计算， 只进行操作的追加，效率很高）。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到 Edits 中。
（HDFS仅支持数据append追加，不支持文件的随机修改）
但是，如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行 FsImage 和 Edits 的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点2nn（SecondaryNamenode），专门用于 FsImage 和 Edits 的合并

此时内存中有一份数据，镜像文件Fsimage中存储的是结果的值，Edits追加的是当前变化的步骤（操作）。
一般来说，Fsimage文件中的数据（备份） + Edits中相关的操作（更新） = 内存中的数据。
开机时，会将FsImage和Edits的数据加载到内存；
关机时，会在2nn中将Fsimage和Edits的数据由2nn进行合并。
合并的触发条件：①定时时间到②Edits中数据满了。

二. NameNode和Secondary NameNode工作过程

第一阶段：NameNode工作机制：
1.第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果不是第一次启动，直接加载镜像文件fsimage和编辑日志Edits到内存。
2.客户端发出对元数据进行增删改的请求。
3.nn会先在Edits中记录流程（日志），再更改内存。（如果先更改内存再记账，中途断电将导致数据丢失）
（如果在Edits中记完账遇到断电也没影响，因为Edits的操作+镜像文件，合并了就是内存中最新的数据）
4.nn在内存中对元数据进行增删查改操作

第二阶段：Secondary NameNode工作机制：
1.2nn询问 nn 是否需要 CheckPoint服务。直接带回nn是否检查结果。
2.2nn 请求执行 CheckPoint。
3.NameNode 滚动正在写的 Edits 日志，将之前的edits_inprogress_001改名为edits_001并创建edits_inprogress_002；之后客户端的请求日志都记录到新的edits_inprogress_002
4.将滚动前的编辑日志（改名为deits_001）和镜像文件fsimage拷贝到 2nn。
5.2nn加载编辑日志edits_01和镜像文件fsimage到内存，并合并。
6.生成新的镜像文件 fsimage.chkpoint。 ★
7.2nn将fsimage.chkpoint拷贝回到 NameNode。 ★
8.NameNode 将 fsimage.chkpoint 重新命名成 fsimage即覆盖原来的镜像文件。 ★
下次再启动的时候会将edits_inprogress_001和新的镜像文件加载到内存当中！

由上可见nn和2nn的区别：nn记录了最新的edits_inprogress_001日志，但2nn都是历史的数据，没有最新的！