NameNode
包含两种重要数据结构
- FsImage：保存系统文件树
FsImage记录内容包括：访问权限，块大小以及组成文件的块，文件的复制等级和文件的修改访问时间。 - EditLog：记录对数据进行的诸如创建、删除和重命名等操作。
系统启动NameNode的时候，首先从磁盘将FsImage内容加载到内存，与EditLog各项操作合并，合并之后得到的是最新的元数据。这个最新的元素作为新版的FsImage，之后系统会重新创建一个空的EditLog，记录后续的更新操作。
为什么不把所有的更新操作就记录到FsImage中去，新的FsImage不就是旧的FsImage和EditLog的合并吗？为什么还要开一个新的空的EditLog，为什么需要EditLog这个数据结构？
答：EditLog 的存在是一种优化策略，只使用FsImage的时候，FsImage本身的size会很大，若每次修改和更新的信息都去去更新到FsImage中去，系统运行速度效率会很慢。EditLog的Size小。
在启动之后，EditLog也是在内存中的，自然会随着操作数量的增多而size变大，影响运行速度，如何解决？
答：有一个所谓的Secondnary NameNode，该NameNode除了作为第一NameNode的冷备份之外，还用来对EditLog进行处理。
第二NameNode和第一NameNode协作处理EditLog的机制？
答：第一NameNode和第二NameNode定期通信，当第一NameNode中的EditLog的size达到一定程度，第二NameNode会通知第一NameNode停止往EditLog中写入信息，此时第一NameNode新建一个edits.new文件用来作为中转缓存文件。第二NameNode会通过http get的方式将第一NameNode节点上的FsImage和EditLog拉到自己的本地，进行合并成一个新的FsImage，在此期间第一NameNode会将更新信息记录在edits.new中，随后第二NameNode会把新的FsImage传给第一NameNode，第一NameNode得到新的FsImage，并将edits.new作为新的EditLog。
节点之间通信协议
通信都是基于TCP/IP
客户端和NameNode进行TCP通信
客户端读数据和dataNode通信，使用的是RPC。
出错检验恢复
NameNode出错：HDFS 2.0 中通过SecondnaryNameNode恢复元数据，通过热备立即顶上去。
DataNode出错：heartbeat，DN有故障直接将其重新复制分发到其他可用节点。
数据本身出错：写文件时会同时写文件内容和该文件的校验码，当其他客户端读文件的时候会把读过来的文件内容进行计算校验码，并与之前写写入的校验码进行比对。
