【学习历程】08 Hadoop之namenode与secondaryNameNode解析

一、问题引入：

    NameNode在集群当中主要负责元数据信息的管理，由于元数据信息需要经常随机访问，因此元数据信息必须可以高效的检索，那么如何保证namenode快速检索呢？元数据信息保存在哪里能够快速检索呢？如何保证元数据的持久安全呢？

解决方案：

1. 为了快速检索，必须将元数据存放在内存 当中。
2. 但是内存中的数据容易丢失，为了保证元数据的安全持久，在hadoop当中利用FSImage文件持久化存储元数据信息。
3. 但随着时间推移，FSImage越来越大，操作也变得越来越难。为了解决元数据信息的增删改查，hadoop还引入了元数据操作日志edits文件，edits文件记录了客户端操作元数据的信息。
4. 但edits信息也会越来越大，为了解决edits文件膨胀的问题，hadoop当中引入了secondaryNamenode来专门做fsimage与edits文件的合并。

二、工作机制

        客户端对hdfs进行写文件时会首先被记录在edits文件中。
        edits修改时元数据也会更新。
        每次hdfs更新时edits先更新后客户端才会看到最新信息。
        fsimage: 是namenode中关于元数据的镜像，一般称为检查点。

namenode工作机制:

1. 第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存
2. 客户端对元数据进行增删改的请求
3. namenode记录操作日志，更新滚动日志
4. namenode在内存中对数据进行增删改查

Secondary NameNode工作机制

1. Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果
2. Secondary NameNode请求执行checkpoint
3. namenode滚动正在写的edits日志
4. 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
5. Secondary NameNode加载编辑日志和镜像文件到内存，并合并
6. 生成新的镜像文件fsimage.chkpoint
7. 拷贝fsimage.chkpoint到namenode
8. namenode将fsimage.chkpoint重新命名成fsimage

三、secondarynameNode如何辅助管理FSImage与Edits文件

1. secondaryNN通知NameNode切换editlog
2. secondaryNN从NameNode中获得FSImage和editlog(通过http方式)
3. secondaryNN将FSImage载入内存，然后开始合并editlog，合并之后成为新的fsimage
4. secondaryNN将新的fsimage发回给NameNode
5. NameNode用新的fsimage替换旧的fsimage