NameNode节点加载FSImage+EditsLog

      在前面的博文中，我曾多次提到过在NameNode的启动过程中有加载FSImage+EditsLog这一必不可少的一项。关于文件fsImage和文件edits是用来存放神马的，我在这里就不用在重复了吧。在本文我将详细的叙述NameNode是如何加载fsimage和edits文件的。

      在NameNode节点启动之前，我们一般会在配置文件hdfs-default.xml中分别配置文件fsImage、edits所在的路径，它们对应配置文件中的项dsf.name.dir、dfs.name.edits.dir。同时，也可以同时配置多个fsImage、edits的路径，其中fsImage和edits也可以有相同的路径。无论是文件fsImage的路径还是文件edits的路径，NameNode都会把它抽象成一个StorageDirectory对象：

因此，每一fsimage的路径被实例化为IMAGE类型的StorageDirectory对象，每一个edits的路径被实例化为EDITS类型的StorageDirectory对象，而既是fsimage又是edits的路径则被实例化为IMAGE_AND_EDITS类型的StorageDirectory对象。对于配置了多个fsimage和edits的路径的启动，NameNode并不会加载加载，而是从IMAGE类型的StorageDirectory集合中挑选一个最新版本的fsimage文件，从EDITS类型的StorageDirectory的集合中挑选一个最新版本的edits文件，当然IMAGE_AND_EDITS类型的StorageDirectory既可以看作是IMAGE类型的，也可以看作是EDITS类型的。至于如何判断一个StorageDirectory是不是最新的，主要是根据StorageDirectory中fstime文件存放的时间戳来确定的。在选取最新的fsimage、edits文件之后还要保证他们的版本相同，否则整个NameNode节点的启动过程失败。下面还是用一张图来描述整个过程吧！

     在理想的情况下，上述过程没有半点问题，但是如果在这一过程中突然出现了宕机或者是断电的异常情况而被迫中断，特别是在保存最新的目录树的时候，那么NameNode在重启之后又是如何恢复的呢？实际上，在上面的流程图中，我故意遗漏了一个相当重要的过程——checkpoint的恢复过程。这个过程在加载当前最新的fsimage文件之前，主要是恢复最新的fsimage、edits目录。

        对于上面的这个简单的恢复过程，在edits.new文件存在的情况下继续完成上一次的加载，而在 edits.new文件不存在的情况下放弃上一次的加载，回到上一次加载之前的状态，这是为什么呢？我会在后面的博文中提及。