NameNode持久化场景引入： 问题：NameNode宕机，导致内存中的文件元数据丢失怎么办？我们知道元数据是存储来内存中的，所以一旦宕机，内存数据是会丢失的，因此为了避免数据丢失，HDFS中出现了该持久化技术。 解决：NameNode会将内存中的元数据持久化到磁盘中。
持久化两大方案：日志持久化、快照持久化
日志持久化概念：将client客户端对HDFS执行的增删改操作命令记录在日志文件中，方便以后宕机数据丢失，再次运行这些操作命令，每当有一个操作命令需要执行，首先记录在editslog 也就是我们的日志持久化文件中，再完成实际操作，保证每一个操作都对应的有日志去完成备份。
日志持久化优缺点：
优点 时效性极高，数据恢复安全，能够完完全全恢复丢失的NN（NameNode）元数据。
缺点 恢复时间长，举个例子，我们对元数据的操作做了N多次很多修改，最后用户将该存储文件删除，我们的元数据中不应该再有该数据，我们之前的editslog日志就白白运行许多命令。
快照持久化概念：每隔一段时间，将内存中的元数据信息，持久化存储起在fsimage快照中。
快照持久化优缺点：
优点 恢复快，比一条条的数据恢复快很多。
缺点 数据持久化不安全，不能保证最后宕机前的部分数据保存在恢复快照中，时效性差。
secondaryNameNode是NameNode的助理，将日志editslog合并到快照fsimage中。如下图所示，首先大概了解下两者合并的机制，我们的日志持久化依然按照来一条操作，记录一条日志的工作机制，当数据达到一定的量，默认100w条时候，完成一个合并操作：系统首先保存一个0号原始快照（fsimage0），然后editslog0记录实时的指令日志，当达到合并时机时，fsimage0和editslog发送到SNN中完成合并，由该助理帮助我们合并成新的快照fsimage1，将fsimage1复制发送给NameNode，以备宕机时候做为最新的快照来回复时间，尽全力保证了快照的时效性。
值得注意的是！我们执行fsimage0和editslog0合并成fismage1的操作的同时，新来的指令会记录在editslog1中，完完全全保证了时效性，这个正在记录实时操作的日志文件，没有达到合并时机（checkpoint）之前，是始终在NN（Namenode）中的，我们一旦宕机，fsimage1和editslog1足以完完全全保证所有信息的恢复。完成了安全的持久化。 
持久化结论：
1. HDFS接受客户端的文件操作后。
2. 先将操作的命令 以日志的方式记录到editslog中。
3. 然后再将指令对应的文件元数据的修改操作，修改内存中的元数据信息。
4. SNN定期负责将editslog中的文件合并到fsimage中，数据恢复时用最新的正在记录的editslog合并最新的fsimage快照即可。
SNNcheckpoint机制:
1. SecondaryNameNode向NameNode发起合并请求
2. NameNode将当前的Editslog文件保存改名edits，并新建EditsLog继续持久化工作。
3. 将改名后的edits文件和本地的FSImage(旧)发送给sencondaryNameNode
4. SecondaryNameNode负责将FSImage(旧)+edits文件合并成FSImage(新)
5. 将新的FSImage(新)发送给NameNode保存。
checkpoint触发条件(时机): 每1分钟检查一次触发条件。(SNN没隔1分钟，访问一次NN)
1. 每隔1小时触发一次checkPoint
2. 每100w次操作，触发一次checkpoint
后续我们需要注意的一些配置操作:SNN和NN在一个服务器是上，存在单点故障。
场景：一旦服务器磁盘崩坏，持久化的数据就会全部丢失。
解决：SNN 和NN放在不同的服务器上。
那么怎么配置SNN的服务器位置呢？可以对hdfs-site.xml中的SNN的节点地址进行配置，需要注意的是我们需要配置文件通过Linux命令发送到所有的服务器中，做到统一。可以用scp命令。
单独启动SecondaryNameNode: hadoop-deamon start secondarynamenode
当面试问到： snn的职责 namenode如何做数据持久化 checkpoint的流程 edis和fsimage分别做什么，这些基本没有差别，我们通过讲述两大持久化方案，合并优点，checkpoint合并机制流程即可。
个人随笔，转载注明引用，已经上传关于HDFS分布式的配置详情文档