Hadoop -- NN和2NN的工作机制

前言

• 记录时间：2022.7.27
• 内容：
  • 1.NN和2NN的工作流程。
  • 2.为什么小秘书2NN不能完全代替老板NN的工作？

一、NN和2NN的工作流程

• 硬盘和内存就像阴阳两极的对立，硬盘可靠但慢，内存快但不可靠。
  那如何利用他俩的共同优势，让结果像太极那样游刃得当呢？
• 借用大海哥的图，自己总结了三个场景的运行流程。

开机启动：
将硬盘里的 edits_inprogress_001（编辑日志）和 fsimage（镜像文件）加载进内存。

客户端client发出操作请求：
1.新建一份空白的 edits_inprogress_002，用作后续的编辑日志写入。
2.将内存里的 edits_inprogress_001 改名为 edits_001，用作数据备份。
3.将操作请求内容写入 edits_inprogerss_002。

CheckPoint触发：（定时时间到/edits中的数据满了）
1.拷贝 edits_001 和 fsimage 到 2NN。
2.加载 edits_001 和 fsimage 到内存，合并生成结果命名为 fsimage.chkpoint。
3.拷贝 fsimage.chkpoint 到 NN。
4.将NN里的 fsimage.chkpoint 重命名为 fsimage ，覆盖掉原来的 fsimage。

二、为什么小秘书2NN不能完全代替老板NN的工作？

回归对NN和2NN操作的全流程，核心矛盾就在于实时处理和实施备份的冲突。

说白了就是，从某个时间节点开始，新建一个空间去存放接下来的操作日志。而原来旧的空间和数据就可以不被新数据追加打扰，可以安心打包了，同样的，这样打包备份起来的数据，是不含有在打包之后新加进来的那些操作记录的。

所以老板NN含有edits_001编辑日志也有edits_inprogress_002编辑日志，但小秘2NN只有edits_001。如果NN崩溃时，edits_inprogress_002是有数据在的，那么这部分数据就是没法恢复回来的。

备注：001和002只是用来代替说明旧和新，实际上是有001 002 003 004……很多的。