先来解释一下HDFS几个节点作用：
1.NameNode节点
A.运行在单个节点服务器上作为主处理器
B.存有文件的元数据(哪个数据块在哪里，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。)
C. 直接访问文件的客户端
fsimage - 它是在NameNode启动时对整个文件系统的快照（文件系统镜像文件）
edit logs - 它是在NameNode启动后，对文件系统的改动序列（其实就是操作记录日志）
这种工作方式的特点：
（1）namenode始终在内存中存储元数据（metedata）,使得“读操作”更加快、
（2）有“写请求”时，向edits文件写入日志，成功返回后才修改内存，并向客户端返回。
（3）fsimage文件为metedata的镜像，不会随时同步，与edits合并生成新的fsimage。
edits文件会在集群运行的过程中不断增多，占用更多的存储空间，虽然有合并，但是只有在namenode重启时才会进行。并且在实际工作环境很少重启namenode，
这就带来了一下问题：
（1）edits文件不断增大，如何存储和管理？
（2）因为需要合并大量的edits文件生成fsimage，导致namenode重启时间过长。
（3）一旦namenode宕机，用于恢复的fsiamge数据很旧，会造成大量数据的丢失。
2.SecondaryNameNode(Checkpoint Node)
A.它的职责是合并NameNode的edit logs到fsimage文件中，而非热点容错。
B.它只是NameNode的一个助手节点，目的是在HDFS中提供一个检查点，维持NameNode的元数据拷贝。
日志与镜像的定期合并总共分五步：
1.SecondaryNameNode通知NameNode准备提交edits文件，此时主节点产生edits.new
2.SecondaryNameNode通过http get方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）
3.SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt
4.SecondaryNameNode用http post方式发送fsimage.ckpt至NameNode
5.NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束。 在新版本的hadoop中（hadoop0.21.0）,SecondaryNameNode两个作用被两个节点替换， checkpoint 6.node与backup node. SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期，fs.checkpoint.size控制日志文件超过多少大小时合并， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。3.DataNode
A. 一般运行在集群中所有节点
B.堵塞 creation/replication/deletion/reads
C.从NameNode获取等级次序
DataNode是文件存储的基本单元，用户写入数据首先在namenode中登记元数据，哪个数据块在哪个服务器上：黄色在1号节点,红色的2号节点 绿色在3号节点。然后HDFS在节点之间复制这些数据块。写文件完成后，当我们开始读文件时，读文件由于是并行读取，因此读取时间会提高三倍。同时DataNode周期性地将所有存在的Block信息报告给NameNode，以完成NameNode元数据信息更新。
4.BackupNode
备份节点，这个结点的模式有点像 mysql 中的主从结点复制功能， NN 可以实时的将日志传送给 BN ，而 SNN 是每隔一段时间去 NN 下载 fsimage 和 edits 文件，而 BN 是实时的得到操作日志，然后将操作合并到 fsimage 里。在 NN 里提供了二个日志流接口： EditLogOutputStream 和 EditLogInputStream 。即当 NN 有日志时，不仅会写一份到本地 edits 的日志文件，同时会向 BN 的网络流中写一份，当流缓冲达到阀值时，将会写入到 BN 结点上， BN 收到后就会进行合并操作，这样来完成低延迟的日志复制功能。
