本文主要是介绍Hadoop商业环境实战-HDFS NameNode 宕机元数据一致保障及SNN机制深入研究，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
版权声明：本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。版权声明：禁止转载，欢迎学习。QQ邮箱地址：1120746959@qq.com，如有任何商业交流，可随时联系。
1 从文件目录树谈起(FSImage与EditLog)
- 文件目录树存在于NameNode的内存里，维护了整个HDFS这个分布式文件系统元数据信息。
- 任何对文件的创建，修改，删除都会在内存中完成，并持久化到磁盘，也即edits log。
- 元数据的存储形式主要有3类：内存镜像、磁盘镜像(FSImage)、日志(EditLog)。
- 在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在NameNode内存;
- 磁盘镜像是某一时刻HDFS的元数据信息的快照，包含所有相关Datanode节点文件块映射关系和命名空间(Namespace)信息，存储在NameNode本地文件系统;
- 日志文件记录client发起的每一次操作信息，即保存所有对文件系统的修改操作，用于定期和磁盘镜像合并成最新镜像，保证NameNode元数据信息的完整，存储在NameNode本地和共享存储系统Quorum Journal Manager(QJM)中。
- SNN会定期将本地FSImage和从QJM上拉回的ANN的EditLog进行合并，合并完后再通过RPC传回ANN。
- 悖论：若频繁的修改内存里的元数据，并持久化，会存在大量的随机IO，则性能极低。因此JournalNodes诞生了，利用ZKFC选举和双缓存机制实现高并发数据读写。
seen_txid: 是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复，如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。
2 Secondary NameNode 优胜劣汰的弃儿（单点故障）
整个核心分为最近更新的edit logs 和全局系统快照fsimage 。NameNode 宕机后，根据其最近更新的edit logs 和全局系统快照fsimage（Secondary NameNode帮忙协助处理的）在重启时更新到内存进行回放，即可重新恢复整个系统的元数据。
- fsimage - 它是在NameNode启动时对整个文件系统的快照 。
- edit logs - 它是在NameNode启动后，对文件系统的改动序列 。
Secondary NameNode 诞生的重点原因阐述：
- hadoop仅有单NameNode时：因为只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。
- 怎么去管理edit logs是一个挑战。 NameNode的重启会花费很长时间，因为有很多改动（在edit logs中）要合并到fsimage文件上。 如果NameNode挂掉了，那我们就丢失了很多改动，因为此时的fsimage文件非常旧。
- 为了减小edit logs文件的大小和得到一个最新的fsimage文件，初期引入了Secondary NameNode机制。
- Secondary NameNode会定时到NameNode中去获取edit logs，并更新到Secondary NameNode 自己的fsimage上。一旦它有了新的fsimage文件，它将其拷贝回NameNode中。 NameNode在下次重启时可以直接使用这个新的fsimage文件，从而减少重启的时间。
- secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。
2 JournalNodes 历史动乱的维护者（集群模式）
-
在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。
-
active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。
-
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。
-
standby状态的NameNode有能力读取JournalNodes中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了。
3 宕机内存元数据一致性回放SNN机制（高可用）
- 第一步：通知hdfs客户端，我要上传一份文件。（提前设置副本）
- 第二步：更新Active NameNode(ANN)的内存元数据，并写一份edits log到JournalNodes集群上，另一份写在本地。
- 第三步：Standby NameNode （SNN）实时读取JournalNodes中更新的 edits log，更新Standby NameNode内存元数据，并每隔一段时间（SNN上有一个线程StandbyCheckpointer），元数据写入到磁盘的fsimage文件中，并同步到Active NameNode。
- 第四步：一旦Active NameNode宕机，Standby NameNode 直接读取最近更新的edits log（不会太多）和 fsimage文件，进行内存中回放，即可实现快速恢复使用。
- 第五步：如果没有宕机，hdfs客户端负责分布式写副本即可。
4 总结
本文在这里详细介绍了宕机内存元数据一致性回放机制。注意这里只是盲人摸象，只有借助QJM和ZKFC的选举机制，同时使用hadoop 分段加锁 + 内存双缓冲机制，才能真正实现每秒上千次的高并发数据访问读写，从而形成了整套数据宕机恢复的体系。
版权声明：本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。
秦凯新 于深圳 201811222049
这篇关于Hadoop商业环境实战-HDFS NameNode 宕机元数据一致保障及SNN机制深入研究的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
