Hadoop之NameNode工作流程（非HA机制）

目录

一、简介

二、功能

1.管理元数据

2.维护目录树

3.响应客户请求

三、工作流程

1.高并发问题

2.具体流程

3.指定checkpoint时间

4.遗留问题

一、简介

NameNode负责：文件元数据信息的操作以及处理客户端的请求
           NameNode管理：HDFS文件系统的命名空间NameSpace
           NameNode维护：文件系统树（FileSystem）以及文件树中所有的文件和文件夹的元数据信息（matedata），维护文件到块的对应关系和块到节点的对应关系
           NameNode文件：namespace镜像文件（fsimage），操作日志文件（edit log）。这些信息被Cache在RAM中，当然这两个文件也会被持久化存储在本地硬盘
           NameNode记录：每个文件中各个块所在的数据节点的位置信息。但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建
           从数据节点重建：在nameNode启动时，DataNode向NameNode进行注册时发送给NameNode

二、功能

1.管理元数据

/test/a.log 是在hdfs文件系统中的路径，3是这个文件的副本数(副本数可以通过在配置文件中的配置来修改的)。在hdfs中，文件是进行分块存储的，如果文件过大，就要分成多块存储，每个块在文件系统中存储3个副本，以上图为例，就是分成blk_1和blk_2两个块，每个块在实际的节点中有3个副本，比如blk_1的3个副本分别存储在h0，h1，h3中

2.维护目录树

3.响应客户请求

三、工作流程

1.高并发问题

namenode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了

因此必须在磁盘中有备份，在磁盘中的备份就是fsImage，存放在namenode节点对应的磁盘中。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦namenode节点断点，就会产生数据丢失

因此，引入edits.log文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits.log中。这样，一旦namenode节点断电，可以通过fsImage和edits.log的合并，合成元数据。但是，如果长时间添加数据到edit.log中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行fsImage和edits.log的合并，如果这个操作有namenode节点完成，又会效率过低。因此，引入一个新的节点secondaryNamenode，专门用于fsImage和edits.log的合并

2.具体流程

（1）namenode节点每隔一定时间或者edits.log达到指定大小，请求secondaryNamenode合并操作

（2）secondaryNamenode请求namenode进行edits.log的滚动，这样新的编辑操作就能够进入新的文件edits.new中

（3）secondaryNamenode从namenode中下载fsImage和edits.log

（4）secondaryNamenode进行fsImage和edits.log的合并,成为fsImage.checkpoint文件

（5）namenode下载合并后的fsImage.checkpoin文件

（6）将fsImage.checkpoint和edits.new命名为原来的文件名(之后fsImage和日志文件edits.log重新恢复初始状态)

 3.指定checkpoint时间

lfs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒

lfs.checkpoint.size    规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M

4.遗留问题

非HA机制下，一旦NameNode宕机了，虽然 fsImage和日志文件edits.log保存了所有操作，但是不能对外提供服务了，只能暂停服务，待NameNode恢复