本文继续 NameNode 启动流程源码剖析，之前讲解了
- Namenode 启动流程跟踪
- Namenode Httpserver 启动流程跟踪
- Namenode 元数据加载跟踪
这次讲解下： Namenode 资源检查和是否进入安全模式的判断
一、 Namenode 安全模式源码分析：资源检查
我们在启动 Namenode 的时候，有时会遇到 Namenode 进入安全模式，所以我们一起也来看看这边吧。Namenode 安全模式的代码藏的比较隐蔽，而且名字起的也很随意。
-
在 NameNode 服务启动跟踪 的第 4 步，最后有一句代码
startCommonServices(conf);这个方法，这个代码看着很普通，但其实资源检查和安全模式都在这里（吐槽下方法名起不直接）
image
-
我们进入到
startCommonServices(conf);方法，可以看到在rpcServer启动前，又调用了namesystem.startCommonServices(conf, haContext);，我们继续跟进：
startCommonServices
-
进入
namesystem.startCommonServices(conf, haContext);方法后，里面的代码就要注意了（这里代码的命名都比较不好，容易忽略）
首先要注意nnResourceChecker = new NameNodeResourceChecker(conf);，NameNodeResourceChecker这个就是 Namenode 的资源检查，我们跟进：
startCommonServices
-
跟进
nnResourceChecker = new NameNodeResourceChecker(conf);后，发现这里是获得了很多 Namenode 的资源目录，包含editlog存储目录（共享、非共享）、Namenode 配置文件中配置的必须目录等，这些目录都是通过配置文件配置的
然后把这些目录传入了addDirToCheck方法，我们继续跟进addDirToCheck方法
NameNodeResourceChecker
-
跟进
addDirToCheck方法后，发现这里把 所有的目录都包装成CheckedVolume对象然后又 put 到volumes变量中，volumes变量是个Map集合，到这里第4步中的nnResourceChecker = new NameNodeResourceChecker(conf);构造函数算是执行完了，我们继续第 4步中的下一步checkAvailableResources()
image
-
跟进
checkAvailableResources()，后发现就一行代码，继续跟进，发现虽然还是一行代码，但是这里把第 5步中的volumes当做参数传过去了，继续跟进
image
image
-
这里就是对所有传进来的目录都进行了校验，具体的校验方法就是
resource.isResourceAvailable(),再看看这个方法
isResourceAvailable
-
此方法是个抽象方法，需要知道它的实现，我们在第5步的时候知道其实这些目录都被封装成了
CheckedVolume对象，所以这个方法的实现类就是CheckedVolume。
image
-
进入
CheckedVolume的isResourceAvailable方法后，发现这里 其实就是判断此目录的剩余空间是否小于某个值availableSpace < duReserved（这个值是100m,具体看配置吧），如果小于配置的值，则返回false，否则是 true。到这里这边checkAvailableResources方法的执行就完成了。
image
二、Namenode 安全模式源码分析：block数 检查
- 其实从6~9就是在给
FSNamesystem.hasResourcesAvailable变量赋值为true或false。我们继续6中的代码，也就是startCommonServices中的下一步，这里有这样一行代码setBlockTotal();，这个代码里就是 启动安全模式 的关键（但是名字起的太普通了）
image
- 我们跟进
setBlockTotal();，这里先看getCompleteBlocksTotal()方法，看方法名应该是获得 完成的block总数。这里要解释下，其实在 HDFS中的 block 包含两个状态 一个是 Complete ，另一个是 UnderConstruction。这里就是获得 Complete 状态的block数量。
setBlockTotal
- 我们跟进
getCompleteBlocksTotal方法看看，看到getBlocksTotal() - numUCBlocks;这个代码,我们应该了解到 complete状态的block数就是使用 总的block减去 UnderConstruction 状态的 block数。具体判断状态，就不看了
getCompleteBlocksTotal
- 我们继续跟进
safeMode.setBlockTotal方法，注意到这里计算了两个值blockThreshold和blockReplQueueThreshold，最后又调用了checkMode()方法
safeMode.setBlockTotal
- 跟进
checkMode()方法，此方法中needEnter()如果返回true就会触发enter()(enter就是进入安全模式)，然后我们看看needEnter()方法具体的逻辑
checkMode
- 进入
needEnter()后，看到代码比较简单，就是有三个判断，只要有任何一个是True，就返回True。那我们仔细看看这三个条件吧
needEnter
-
条件1、 (threshold != 0 && blockSafe < blockThreshold)
如果 blcok 阈值不等于0，且 安全模块(blockSafe) 小于 阈值模块
blockSafe：只要有一个副本就是 blockSafe -
条件2、 (datanodeThreshold != 0 && getNumLiveDataNodes() < datanodeThreshold)
如果 dataNode 活跃最小阈值不等于0，且活跃的 DataNodes 小于最小阈值时，进入安全模式
datanodeThreshold 默认为0，由 dfs.namenode.safemode.min.datanodes 指定
LiveDataNodes: 当前时间 - DataNodes 心跳最后的时间 < 10分30秒 -
条件3、(!nameNodeHasResourcesAvailable());
如果，NameNode 资源检查无效，进入安全模式
三、Namenode 安全模式源码分析：获取Datanode活跃数
前两节分析的就是 第1个条件和第3个条件，而第2个条件并没有分析，我们这一节就看看这个代码。
needEnter
- 先看
datanodeThreshold在哪里赋值的，通过搜索发现该变量是在配置文件中配置的，dfs.namenode.safemode.min.datanodes，默认值是0，所以默认情况下，2 这个条件直接就不判断了。但是我们还可以继续看看判断Datanode活跃的代码。
image
- 跟进
getNumLiveDataNodes()，看到就一句代码
image
- 继续跟进
.getNumLiveDataNodes();，可以看到，判断Datanode是否活跃的主要代码其实就是!isDatanodeDead(dn)，也就是说，不是死亡的 datanode就是活跃的
image
- 继续跟进
!isDatanodeDead(dn)，可以看到就一句代码，此代码就是计算 datanode是否死亡的代码。node.getLastUpdateMonotonic()就是最后一次心跳的时间 ，monotonicNow()就是当前时间，heartbeatExpireInterval是心跳过期间隔；
所以计算公式就是：
如果 当前时间 - 最后一次心跳时间 > 心跳过期间隔 那么就认为Datanode死亡了。
image
- 最后看看
heartbeatExpireInterval是多少呢？
heartbeatRecheckInterval默认是5分钟，heartbeatIntervalSeconds默认是3秒，他们在配置文件里都有配置，具体代码就不跟了。
image
4. 总结
到此：Namenode 安全模式的代码就分析完了。这里画个图简单的描述情况
image
网友评论