NameNode对命名空间的管理

最近继续在看《Hadoop 2.X HDFS源码剖析》，现在看到了第三章NameNode部分。NameNode在hdfs这种文件系统中充当着master的角色，负责的功能有很多比如文件系统目录管理（命名空间管理）、数据块管理、数据节点管理、租约管理、缓存管理等等。这次主要写关于命名空间管理的笔记。

创新互联专注于孟津企业网站建设,自适应网站建设,商城开发。孟津网站建设公司,为孟津等地区提供建站服务。全流程按需网站制作，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务

1. 基本类型

hdfs中最基本的类应该就是INode了，无论是最后的目录、具体文件、软连接还是添加快照功能之后的引用都是这个类的子类，继承关系如下图所示

图表一

INode：包括parent这个字段表明父INode，还提供了isFile()、isDirectory()、isRoot()这些接口；

INodeWithAddtionalFields：包括id、name、permission、features这些字段，进一步拓展基本信息；

INodeFile：在父类的基础上定义了header以及bolcks（BlockInfo[]类型），对应的feature可以表示是否在构建中（underconstruction），是否有快照（snapshot）；

INodeDirectory：在父类的基础上增加了childern字段，表明所有的子INode，对应的feature可以有是否有快照（snapshot），是否有限额（quota）；

INodeReference：这个类以及子类主要是在开启快照功能的时候使用，在介绍之前首先介绍一下快照，所谓快照就是保存这个目录当前状态，这样不论以后对这个目录里面的文件做了删除、增加还是重命名，都可以通过快照获取这个时间下目录的所有文件；

就像下面的图表二所示

图表二

在t0时，存在文件/A/TXT，并且建立了对应时间/A目录的快照snapshot:t0，那么当t0之后将TXT移动到/B目录的时候，直接访问A是找不到文件的，但是可以通过访问/A这个INodeWithAdditionalFields对象的feature数组，访问到t0时刻的快照，接着就可以根据相应的INodeReference对象，找到TXT文件现在对应的位置。

这里WithName可以理解为文件修改之前的位置，DSTReference可以理解为文件修改之后的位置，他们都会指向一个WithCount，但是WithName跟前者可以使多对一的关系，因为可以存在多个保存了TXT这个文件的快照，而只能有一个DstReference表示这个文件当前的路径（WithCount的parent对象就是DstReference），最后WithCount指向了真正的文件/B/TXT。

1. 关于日志

关于日志的细节很多，但是印象最深的地方只有如下两点（或许是我看的不够深入吧、[捂脸]）：

1） 日志采用双缓冲的方式，同时进行逻辑以及物理IO：
    这个缓冲区是由Ready（磁盘IO）以及Current（内存IO）两个部分组成的，写日志的线程，负责将日志写入Current中，而当Current写满了，需要保存到硬盘上的时候，将两块区域调换名字即可，这样日志持久化的操作不会影响当前日志的写入操作；

2） 由于可以存在多个写入日志的地方，调用写日志的时候使用一个保存所有输出流的集合journalSet进行调用，很方便：

journalSet对象有一个selectInputStreams的方法，用于选择需要输出的日志输出流，这样就把journalSet与需要输出的流绑定到一起了，接着直接调用journalSet.startLogSegment方法开始写入日志。

1. 关于FSImage

这个类负责保存命名空间到磁盘、启动时加载fsImage文件以及加载editlog文件：

1） 保存命名空间：

保存的命名空间按照以下格式将内存中的内容，保存到磁盘中，如图表三所示

图表三

MagicNumber：魔数已经在很多技术中被采用了，相当于标识这个文件是哪种类型的文件，例如class文件的'CAFEBABE'；

Sections：这是真正记录内存中数据的部分，例如INode信息、cache信息、快照信息等等；

FileSummary：这部分相当于sections的元数据，描述着每个section的长度以及起始位置；

FileSummaryLength：这部分描述FileSummary的长度。

启动的时候NameNode重后往前，先看FileSummaryLength，然后读取FileSummary，然后在根据各个section的元数据将Section加载到内存中，MagicNumber对应'HDFSIMG1'。

2） 关于检查点

为了防止加载过大的editlog文件而导致的namenode启动太慢，向数据库里面一样，hdfs也有自己的检查点机制（当然没了数据库之中的回滚段什么的，所以还比较简单）。

在非HA的情况下，检查点操作都是由SecondaryNamenode进程操作的，然而在HA的情况下，都是由standbynamenode进行检查点操作，操作完成之后再传递给active namenode。

以上情况都是hadoop2.6.0中namenode的实现，版本不同具体实现也会不一样。相关截图已经打包上传。

                                                                                             2017.2.19