HDFS - CheckPoint机制是怎么实现的

HDFS - 什么是元数据我们提到了CheckPoint机制，主要就是合并多个edits文件，NameNode的压力已经很大了，所以合并的事情，并不是NameNode来做的，而是SecondaryNamenode来支持的，如果在高可用集群或者联邦集群，那合并的事情，就是有standby节点的NameNode来做的。

SecondaryNamenode

HDFS - 什么是元数据中提到了磁盘中的元数据包括fsimage、edits_inprogress、edits、seen_txid、VERSION这些文件。
刚开始的时候，是没有edits文件的。

当NameNode运行一段时间后，就开始慢慢的生成多个edits文件，文件名格式是edits_数字-数字（数字是19位的，我这里画图写了4位），并且是递增的。

前面的文章说过，NameNode重启的时候，就会加载edits_inprogress、edits、以及fsimage这几个文件，因为这几个文件合起来就是完整的元数据。由于edits会越来越多，所以就需要进行合并，提高启动的速度，但是NameNode的压力已经很大了，所以需要SecondaryNamenode来做。
SecondaryNamenode会隔一段时间就去请求NameNode获取fsimage和edits文件，如果两次CheckPoint的时间已经超过1个小时或者两次CheckPoint的操作记录已经超过10w条，那NameNode就会生成一个空的edits.new文件，同时把edits文件以及fsimage文件发送给SecondaryNamenode。

SecondaryNamenode就会在本地把edits文件和fsimage文件进行合并，生成一个新的fsimage.ckpt文件。

生成后的fsimage.ckpt就会发给NameNode，NameNode就会把这个文件覆盖原来的fsimage，fsimage_0006此时后面的数字，对应着edits_0001到edits_0006的元数据集合。此时就会把旧的edits删除，并且把edits.new文件重命名edis文件。
有时候我们会看到fsimage会有两个，这个是为了最新fsimage不可用的时候，能回滚之前的元数据状态，当然新增的元数据就丢失了。

集群

如果非集群的话，元数据的持久化是写入磁盘，如果是集群的话，元数据除了写入磁盘，还会写入JournalNode。所以刚开始的时候，active节点的NameNode和JournalNode的元数据是一样的。

standby节点的NameNode，每隔60秒，就会去JournalNode读取元数据信息。

当CheckPoint触发的时候，就会把edits文件和fsimage文件，合并生成新的fsimage文件。

然后standby节点的NameNode就会把新的fsimage发送给active节点的NameNode。active节点的NameNode替换旧的fsimage，就会把edits文件删除。

至此，完成了edits文件和fsimage的合并。