工作机制

NameNode中元数据的存储介质？
磁盘？内存？
如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客戶请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果更新FsImage，就会导致效率过低，但如 果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文 件(只进行追加操作，效率高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到 Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。

但是，如果⻓时间添加到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间很⻓。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又回效率过低。因此引入一个新的节点SecondearyNamenode，专⻔用于FsImage和Edits的合并。

Fsimage:NameNode内存中元数据序列化后形成的文件。
Edits:记录客戶端更新元数据信息的每一步操作(可通过Edits运算出元数据)。

第一阶段：NameNode启动

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

第二阶段：SecondaryNameNode工作

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

FsImage和Edits解析

Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件inode的序列化信息。
Edits文件：存放HDFS文件系统的所有更新的路径，文件系统客戶端执行的所有写操作首先会被记录到Edits文件中。
seen_txid文件保存的是一个数字，就是最后一个edits_的数字
每次NameNode启动的时候都会将Fsimage文件读入内存，加载Edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成NameNode启动的时候就将Fsimage和Edits文件进行了合并。
查看fsimage
查看edits

DataNode

DataNode机制：

  1. 一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的⻓度，块数据的校验和，以及时间戳。
  2. DataNode启动后向NameNode注册，通过后，周期性的向NameNode上报所有的块信息。
  3. 心跳是每 3 秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过 10 分钟没有收到某个DataNode的心跳，则认为该节点不可用。
  4. 集群运行中可以安全加入和退出一些机器。

数据完整性

思考：如果电脑磁盘里面存储的数据是控制信号灯的红灯信号（ 1 ）和绿灯信号（ 0 ），但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？同理DataNode节点上的数据损坏了，却没有发现，是否也很危险，那么如何解决呢？如下是DataNode节点保证数据完整性的方法。

  1. 当DataNode读取Block的时候，它会计算CheckSum。
  2. 如果计算后的CheckSum，与Block创建时值不一样，说明Block已经损坏。
  3. Client读取其他DataNode上的Block。
  4. 常⻅的校验算法crc（ 32 ），md5（ 128 ），sha1（ 160 ）
  5. DataNode在其文件创建后周期验证CheckSum。