先上图，文章以后再上
截图有先后 所以有些延迟，但是不耽误总体的理解(active-nn=a-nn=active-namenode; s-nn=standby-nn=standby-namenode; journalnode=jn；edits_log=elog ； fsimage=fsg )
一般认为journalnode有2n+1台，如果大于等于n+1台成功写入，就算写入jn成功。
standby-nn 会定时拉取3台jn节点（假设有3台jn）的edits_log（只拉取处于finalized状态的edits_log，in-progress并不会拉取因为他可能会改变），再与本地的fsimage元数据镜像文件做merge操作（ s-nn 并不会同时把edits_log 写入到本地磁盘上。下图中磁盘有edits_log是因为他之前是active-nn(从最后修改时间也可以看出来)。合并操作是在standby-nn内存中完成，完成后会落地新fsimage文件如下图）。
当standby-nn merge完毕后，旧的fsimage不会立即删除而会保留一段时间等待被roll掉，当然版本号会比新merge的fsimage要小。与此同时standby-nn会把新merge的镜像文件推给active-nn ，active-nn旧的镜像也不会立即删除，也是等待被roll掉，新推过来的fsimage镜像也是要比旧的镜像编号要大。
注意：s-nn会比a-nn少一些元数据信息（少的是s-nn在拉取elog时处于in-progress的日志），所以当a-nn宕机或处于非健康状态时，s-nn在切换成a-nn之前要重新拉取大于本地fsg号的elog文件做merge操作，这样s-nn才是最新的元数据，可以切换成a-nn了。
（TODO:这里有个疑问，就是a-nn处于异常状态的那一刻会有elog处于in-progress，a-nn来不及处理这部分elog(比如a-nn突然宕机)，s-nn是如何处理这部分elog的）更多细节会贴源码介绍
