目录
一. HDFS架构简介
二.角色功能
三.常用的持续化方案
四. HDFS元数据可持续化
五.部署次级命名
六.总结
一、HDFS 架构简单介绍HDFS是主从/Slaves的体系结构，由NameNode和几个DataNode组成。 其中，NameNode为主，DataNode为辅。 文件元数据由NameNode负责存储和管理，并维护分层文件目录树。 文件的数据由DataNode按照block保存，并按照block读写。 DataNode和NameNode通过心率维持，DataNode向NameNode报告自己拥有的block信息。 客户端与NameNode交换文件元数据，并与DataNode交换块数据时。
二、角色功能
从HDFS的体系结构来看，它包括两个重要的角色： NameNode和DataNode。 其中，NameNode将文件元数据、目录结构和文件块映射完全存储在内存中，因此需要持久化方案来保证数据的可靠性。 DataNode基于磁盘存储块，保存对块的验证，从而保证块的可靠性； DataNode和NameNode之间由心率保持，向NameNode报告block状态。
三、常用的持久化方案
许多基于内存的存储在使用持久化时，通常有几种方式：日志文件、内存Dump和两种混合方法。 首先，介绍常用的缓存系统—— Redis。 Redis的持续化方式分为AOF、RDB、混合方式。 Redis的AOF是一个日志文件，将每个命令记录在文本文件中。 RDB是内存Dump方式，全部保存内存的信息。 混合方式是AOF和RDB两者共享的方式。 (Redis为了解决AOF体积的问题，提供了AOF改写的命令)
四、HDFS 元数据的持久化
NameNode由于将文件元数据、目录结构、文件块的映射等信息保存在存储器中，所以为了保障可靠性需要将其永久化。 由于日志文件方式和内存Dump各有利弊，所以HDFS也使用混合方式。 HDFS也同样并用了这两种方式，将其日志记录方式称为EditsLog，将其存储器Dump方式称为FsImage。 由于EditsLog和FsImage也有日志记录和内存Dump的固有缺点，所以使用这两种方式弥补对方的缺点。
FsImage严格来说不能说是内存Dump。 因为FsImage的创建是在HDFS部署后格式化时生成的。 第一次启动NameNode时读取的是空的FsImage文件。 当然，可能有内部结构，但不包含元数据等信息。 在随后的NameNode启动时，去阅读EditsLog和FsImage。 此时，所有的EditsLog记录都将作用于内存中的FsImage，将新版本的FsImage从内存保存到磁盘，并删除旧的EditsLog文件。 这样，HDFS的内存就可以获得上次关闭时的全部数据。
FsImage需要滚动更新。 FsImage滚动更新从当前FsImage和增量EditsLog文件创建新的FsImage文件，并用新的FsImage替换旧的FsImage文件，而不是内存Dump。 增量的EditsLog文件将被删除，新的EditsLog文件将被重新记录。
注： NameNode持久性不包括每个文件的块位置。 这是因为DataNode会主动上报文件块的位置。
五、Secondary NameNode 的引入
HDFS为NameNode提供了一个名为Secondary NameNode的秘书，因为滚动和更新FsImage文件是一个非常耗时的原因。 Secondary NameNode不是第二个NameNode，因为它不保存元数据。 完成FsImage和EditsLog的集成。 Secondary NameNode和NameNode通常不在同一主机上。 Secondary NameNode通过http get方式获取NameNode主机上的FsImage和EditsLog，合并后通过http post方式提交给NameNode，生成新的FsImage文件。
当Secondary NameNode拉拽EditsLog时，NameNode会在新的EditsLog中记录新日志。
六、总结
学习HDFS的持续化时，考虑了Redis的持续化。 很多技术的实现都不一样，因为它们在理论上几乎是一样的，或者是死板的。 在这里模拟地感觉，理解其他技术会变得容易。 总结了HDFS的主/从体系结构NameNode和DataNode。 HA模式中还有主控的概念，涉及到选择主控的一致性算法等知识。 之后整理一下，希望喜欢的读者好啊，关注。