namenode和datanode机制

首先咱们看一下NAMENODE:

咱们已经知道了NAMENODE做为DATANODE的管理者，其重要性不言而喻，那么NAMENODE是怎么管理数据的呢？

首先，咱们看一下上面这张图，每次客户端读写数据都要先通过NAMENODE，其实就是先查询NAMENODE中的元数据，那么问题来了，NAMENODE中的元数据到底是存在内存中仍是存在硬盘中呢？若是存在内存中，一旦断电就意味着数据的丢失；可是存在硬盘中，读写速度必然降低。下面将对其细节进行详尽的阐述。

经过看以上这幅图，咱们能够看到NAMENODE中的元数据既存在在内存中，也存在在硬盘中。咱们先看一下元数据的存储细节：

从左到右依次是存储路径，有哪些副本，每一个副本在哪些主机上面存储。NAMENODE是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，文件/目录的元信息和每一个文件对应的数据块列表，接受用户的操做请求。

文件包括：

1.fsimage:元数据镜像文件，存储某一时段NAMENODE内存元数据信息。

2.edits:操做日志文件。

3.fstime:保存最近一次checkpoint的时间。

如今咱们回到上一幅图，

1.NAMENODE始终在内存中保存meta.data，用于处理“读请求”。

2.到有“写请求”到来时，NAMENODE会首先写edits到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，而且向客户端返回。

3.Hadoop会维护一个fsimage文件，也就是namenode中meta.data的镜像，可是fsimage不会随时与NAMENODE内存中的meta.data保持一致，而是每隔一段时间经过合并edits文件来更新内容。Secondary NAMENODE就是用来合并fsimage和edits文件来更新NAMENODE的meta.data的。

 

这里就用到了Secondary NAMENODE，咱们再来看一张图：

 

在这张图中，咱们能够看到SN的一些做用，当NN通知SN要进行checkpoint操做的时候，NN就中止向edits日志中写数据了，可是写操做又不能中止，这时候就会向一个edits.new日志文件中写数据，而SN会把fsimage和edits里面的内容下载到SN中，在SN中进行合并，说白了，就是将日志格式转化成要存储的文件格式，产生fsimage.chkpoint文件，并将它上传给NN，替换fsimage，而且重命名成fsimage，同时edits.new替换edits，而且重命名成edits。详细过程就是：

那么何时checkpoint呢？有两种判别方式：

1.fs.checkpoint.period:指定两次checkpoint的最大时间间隔，默认是3600秒。

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

两种断定方式先达到哪一个断定条件，则先采用哪一个。

咱们再来看一下DATANODE:

DataNode

提供真实文件数据的存储服务

文件块：最基本的存储单位，对于文件内容而言，一个文件的长度大小是size，那么从文件的0偏移，按照固定的大小，顺序对文件进行划分并编号。划分好的每一块称为一个Block，默认Block的大小是128M。开始不一样于普通文件系统的是HDFS中，若是一个文件小于一个数据块的大小，并不占用整个数据块存储空间。datanode与namenode保存心跳机制，当长时间未向namenode报告，则视为该datanode死机，namenode会从新备份该datanode上的数据块。