1. hadoop中HDFS的NameNode原理
1.1. 组成
- 包括HDFS（分布式文件系统），YARN（分布式资源调度系统），MapReduce（分布式计算系统），等等。
1.2. HDFS架构原理
- 比如现在要上传一个1T的大文件，提交给HDFS的
Active NameNode（用以存放文件目录树，权限设置，副本数设置等），它会在指定目录下创建一个新的文件对象，比如access_20180101.log - 至于具体数据，它会将它拆分后进行分布式存储，分散在各个DataNode节点，且默认都会有3个副本，防止其中一台机器宕机使得数据缺失
- 这里图之所以这么复杂，原因在于大量的请求提交给
Active NameNode会不断修改元数据，而元数据是在内存的，为了防止宕机丢失，必须把它存在磁盘，但是频繁的修改磁盘数据，性能是很低的，这是大量的磁盘随机读写，所以有了上述图的方案 - 每次操作请求
Active NameNode会写一条edits log放到磁盘文件，不是直接修改磁盘文件内容，而是顺序追加，这个性能就高多了 - 同时它会把
edits log还会写入JournalNodes集群，通过JournalNodes会把操作日志传到Standby NameNode，这就相当于是个备份服务，确保了Standby NameNode内存中的元数据和Active NameNode是一样的，而Standby NameNode每隔一段时间会把内存里的元数据写一份到磁盘的fsimage文件，这个文件就是全量的元数据了，不是日志记录 - 再然后会把这个fsimage上传到
Active NameNode，替换掉内存中的元数据，再清空掉Active NameNode所在磁盘上的edits log，重新开始记录日志 - 为什么要这么做？因为为了防止
Active NameNode突然宕机后，我们需要进行恢复，它的恢复是基于磁盘上的edits log的，和redis的aof相同的道理，它需要重新运行一遍日志中的所有命令，当时间长了后日志可能会很大，重启时间也就会很长； - 引入
Standby NameNode的备份机制，就可以在节点重启时，直接从Standby NameNode的fsimage读取元数据备份，这就相当于redis的rdb恢复，速度是比较快的，读取完备份再从磁盘的edits log读取少量的操作日志执行恢复，就完全恢复到宕机前的状态了
1.3. NameNode如何承载每秒上千次的高并发访问
- 分段加锁机制+内存双缓冲机制（老实说我是没看懂，他的博客我也留言问了两个问题，有能看懂了拜托这里留言或在他博客
过眼云烟本尊这个评论者下留言，Thanks♪(･ω･)ﾉ） - 我特别不懂的地方就是既要保证顺序性，为什么还能用多线程并发？
参考：
用大白话告诉你小白都能看懂的Hadoop架构原理
大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问