关于面试--【namenode&fsimage&edits】

Namenode:功能

1. 文件名、目录结构、文件属性权限、生成时间、副本数。
2. 数据块和DataNode之间的地址映射关系
3. 元数据文件的操作
4. 负责管理client客户端请求，数据流不经过namenode只是通知与那个DataNode联系。文件数据块到底存放到哪些DataNode上，是由NameNode决定的，NN根据全局情况做出放置副本的决定，读取文件的时候，NN尽量让client读取离它最近的datanode上的副本，降低带宽消耗和读取时延
5. 周期性的接受心跳和块的状态报告信息（包含该DataNode上所有数据块的列表）若接受到心跳信息，NN认为DN工作正常，如果在10分钟后还接受到不到DN的心跳，那么NN认为DN已经宕机
   这时候NN准备要把DN上的数据块进行重新的复制。
   块的状态报告包含了一个DN上所有数据块的列表，blocks report 每个1小时发送一次
6. 容错机制

没有Namenode，HDFS就不能工作。事实上，如果运行namenode的机器坏掉的话，系统中的文件将会完全丢失，因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此，namenode的容错机制非常重要，Hadoop提供了两种机制。

第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统（NFS）。

第二种方式是运行一个辅助的Namenode(SecondaryNamenode)。 事实上SecondaryNamenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，SecondaryNamenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。

但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件

系统(NFS)中的Namenode的元数据文件来使用。

Edit是什么？

1. edits为二进制文件，记录对HDFS的各种更新操作，客户端执行所有的写操作都会被记录到editlog中。
2. 比如创建文件，删除文件。打开、关闭、重命名文件和目录，都会生成一个edit记录。
3. 客户端对hdfs进行写文件时会首先被记录在edits文件中。
4. edits修改时元数据也会更新。每次hdfs更新时edits先更新后客户端才会看到最新信息。

 Fsimage是什么？

fsimage为二进制文件，保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件信息。

对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。

对于文件来说包括数据块描述信息、修改时间、访问时间等；

简单的说，Fsimage就是在某一时刻，整个hdfs的快照

就是这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，副本个数等。

【注意】Block的位置信息不会保存到fsimage，由DataNode在向NameNode进行注册时重新加载和定期加载。

一般开始时对namenode的操作都放在edits中，为什么不放在fsimage中呢？

因为fsimage是namenode的完整的镜像，内容很大

如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。

把文件和目录的元数据信息持久化地存储到fsimage文件中，每次启动时从中将元数据加载到内存中构建目录结构树

之后的操作记录在edits log中，定期将edits与fsimage合并刷到fsimage中

seen_txid 是什么？

seen_txid文件保存的是一个数字，就是最后一个edits_的数字

 NameNode启动和接受请求

1、启动namenode 

每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的。

2、当NameNode接收到写请求之后

1. 会先将该请求记录到edits_inprogess文件中，如果记录成功，将该请求同步更新到内存中，修改内存中的元数据，内存修改完成之后会给客户端分会一个ack表示成功。
2. hdfs会给每一次的写操作分配一个编号-事务id-txid
3. 当edits文件达到更新条件回会更新到fsimage中更新条件
   1. 文件大小：当edits_improgress文件达到指定大小会触发更新，默认是64M 大小可以由fs.checkpoint.size（core-site.xml）来指定，默认单位是字节
   2. 时间大小：当距离上一次更新达到指定时间间隔触发，默认是1H 大小设置fs.checkpoint.period来指定，默认单位是秒 ambari集群配置
   3.  dfs.namenode.checkpoint.txns默认设置为1百万，定义NameNode上的未经检查的事务的数量，这将强制紧急检查点，即使尚未达到检查点周期。
   4. 重启更新：NameNode重启之后，会自动的将edits_inprogress中的操作更新到fsimage中
   5. 强制更新：hadoop dfsadmin -rollEdits
4. 在更新的时候，会将edits_inprogress重命名为edit_******-******,同时产生一个新的edits_inprogress
5. 如果是HA模式更新过程发生在SecondaryNamgenode 通过http get方式拉过去