白话理解Hadoop的NameNode和SecondaryNameNode工作机制

NameNode里的元数据是用来找到DataNode的，但是这些元数据是存储在哪里的呢？
元数据的存储位置无非是存储在内存里或者硬盘里，但是存在硬盘里，主机访问的时候时间太长，放在内存里，会明显提高访问的效率，但是存在内存里也有一个坏处，就是一旦设备断电，内存里的元数据也会消失，所以需要对元数据进行持久化。
元数据持久化有两种方式:一种是fsimage，一种是edit日志。fsimage是edit日志的一个汇总。edit日志产生的原因是如果我们每次都是将数据存在fsimage里面，那么我们重启集群之后，加载这个fsimage需要更多的时间，每次往里面写，也会使效率变低。而edit是一个个小的文件，每次当元数据有更新的时候，都会将内存中的元数据加载到edits文件里。
SecondaryNameNode在集群里扮演什么角色呢？其实可将SecondaryNameNode理解为一个NameNode的秘书，由它来合并edits和fsimages文件。这样，我们每次集群加载的就是合并之后的新的fsimage文件了。
这里给出一个NameNode和SecondaryNameNode工作机制的图片：

第一阶段：NameNode的启动：
（1）当第一次启动NameNode的时候，首先会创建fsimage文件和edit文件。如果不是第一次启动NameNode的话，会先加载里面的fsimage文件和edit文件。
（2）这时候客户端来了一个数据增删改查的一个请求，那么这个请求会先被记录在edit文件里面，更新这个有了新的请求的edits文件，后加载到内存中，对元数据进行增删改查。
第二阶段：Secondary NameNode工作
这时候我们namenode的秘书Secondary NameNode就要出来工作了。
(1)我们的Secondary NameNode时不时要问问namenode老板需不需要Checkpoint(这里可以理解为需不需要更新一个fsimage啊)，但是老板什么时候可能会答应呢？就是当namenode里面的edit中的数据太多了。
老板会说：小s啊（Secondary NameNode），更新一个吧。
但是有时好心的Secondary NameNode也会主动帮忙更新，就是当设定的必须更新的时间到了，必须更新了，这时候就不会管老板愿不愿意了，直接更新。
（2）然后我们的namenode老板会滚动正在写的日志，将这个日志送给Secondary NameNode。因为刚刚namenode老板把那个日志给滚动了，所以之前的edit文件不能再写了。同时，会再生成一个edits文件，让namenode的剩余的操作写在这个新的edit文件里面。
（3）既然edit文件都送给Secondary NameNode秘书了，那么就再送一个吧。把这个fsimage文件也给秘书。老板说：小s啊（Secondary NameNode），我这个集群每次都要fsiamge和edit两个文件，年岁已大，有点力不从心了，能不能处理一下给我合并一下。秘书转念一想：这不太容易了嘛，随后开口和namenode老板说道：这个不难，交给我吧。
（4）Secondary NameNode秘书拿到namenode老板送的fsimage文件和edit文件，将这两个文件先加载到内存里，然后在内存里合并。再生成新的f并重命名为simage。chkpoint文件。做完任务的Secondary NameNode傻得像个孩子。然后屁颠屁颠的给老板namenode送了fsimage.chkpoint去。
(5)收到fsimage.chkpoint的老板namenode马上将这个宝贝命名为fsimage。
上面就是NameNode和SecondaryNameNode的工作机制。这使得SecondaryNameNode只是处理合并fsimage和edit文件，而namenode做好一个大老板该做的事情。这样就有效的提高了集群之间的工作效率，而且不用担心集群会突然断电导致元数据损失的这种情况。namenode也是两种持久化方案。用大的状态文件fsimage来保存总的集群的状态，将一些小的操作保存在edit文件里面，这样，就不会发生元数据损失。同时，也提高了集群加载fsimage的速度。
本文仅是自己的白话的理解，可能存在疏漏的地方，如有发现，欢迎大家在下方评论。