Hadoop源码分析-Namenode 安全模式源码深度剖析

本文继续 NameNode 启动流程源码剖析，之前讲解了

1. Namenode 启动流程跟踪
2. Namenode Httpserver 启动流程跟踪
3. Namenode 元数据加载跟踪
   这次讲解下： Namenode 资源检查和是否进入安全模式的判断

一、 Namenode 安全模式源码分析：资源检查

我们在启动 Namenode 的时候，有时会遇到 Namenode 进入安全模式，所以我们一起也来看看这边吧。Namenode 安全模式的代码藏的比较隐蔽，而且名字起的也很随意。

1. 在 NameNode 服务启动跟踪 的第 4 步，最后有一句代码startCommonServices(conf); 这个方法，这个代码看着很普通，但其实资源检查和安全模式都在这里（吐槽下方法名起不直接）
   

   image

2. 我们进入到 startCommonServices(conf);方法，可以看到在 rpcServer 启动前，又调用了namesystem.startCommonServices(conf, haContext);，我们继续跟进：
   

   startCommonServices

3. 进入 namesystem.startCommonServices(conf, haContext); 方法后，里面的代码就要注意了（这里代码的命名都比较不好，容易忽略）
   首先要注意 nnResourceChecker = new NameNodeResourceChecker(conf); ，NameNodeResourceChecker 这个就是 Namenode 的资源检查，我们跟进：
   

   startCommonServices

4. 跟进 nnResourceChecker = new NameNodeResourceChecker(conf); 后，发现这里是获得了很多 Namenode 的资源目录，包含editlog存储目录（共享、非共享）、Namenode 配置文件中配置的必须目录等，这些目录都是通过配置文件配置的
   然后把这些目录传入了 addDirToCheck 方法，我们继续跟进addDirToCheck方法
   

   NameNodeResourceChecker

5. 跟进addDirToCheck方法后，发现这里把 所有的目录都包装成 CheckedVolume 对象然后又 put 到 volumes 变量中，volumes 变量是个Map集合，到这里第4步中的 nnResourceChecker = new NameNodeResourceChecker(conf); 构造函数算是执行完了，我们继续第 4步中的下一步checkAvailableResources()
   

   image

6. 跟进 checkAvailableResources()，后发现就一行代码，继续跟进，发现虽然还是一行代码，但是这里把第 5步中的 volumes 当做参数传过去了，继续跟进
   

   image
   image

7. 这里就是对所有传进来的目录都进行了校验，具体的校验方法就是 resource.isResourceAvailable(),再看看这个方法
   

   isResourceAvailable

8. 此方法是个抽象方法，需要知道它的实现，我们在第5步的时候知道其实这些目录都被封装成了CheckedVolume对象，所以这个方法的实现类就是CheckedVolume。
   

   image

9. 进入CheckedVolume的isResourceAvailable方法后，发现这里 其实就是判断此目录的剩余空间是否小于某个值availableSpace < duReserved（这个值是100m,具体看配置吧），如果小于配置的值，则返回false，否则是 true。到这里这边 checkAvailableResources 方法的执行就完成了。
   

   image

二、Namenode 安全模式源码分析：block数 检查

1. 其实从6~9就是在给FSNamesystem.hasResourcesAvailable变量赋值为true或false。我们继续6中的代码，也就是startCommonServices中的下一步，这里有这样一行代码 setBlockTotal();，这个代码里就是 启动安全模式 的关键（但是名字起的太普通了）
   image
2. 我们跟进setBlockTotal();，这里先看 getCompleteBlocksTotal() 方法，看方法名应该是获得 完成的block总数。这里要解释下，其实在 HDFS中的 block 包含两个状态 一个是 Complete ，另一个是 UnderConstruction。这里就是获得 Complete 状态的block数量。
   setBlockTotal
3. 我们跟进getCompleteBlocksTotal 方法看看，看到getBlocksTotal() - numUCBlocks;这个代码,我们应该了解到 complete状态的block数就是使用 总的block减去 UnderConstruction 状态的 block数。具体判断状态，就不看了
   getCompleteBlocksTotal
4. 我们继续跟进safeMode.setBlockTotal方法，注意到这里计算了两个值 blockThreshold 和 blockReplQueueThreshold，最后又调用了checkMode()方法
   safeMode.setBlockTotal
5. 跟进 checkMode()方法，此方法中needEnter()如果返回true就会触发enter()(enter就是进入安全模式)，然后我们看看needEnter()方法具体的逻辑
   checkMode
6. 进入 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

1. 先看 datanodeThreshold 在哪里赋值的，通过搜索发现该变量是在配置文件中配置的，dfs.namenode.safemode.min.datanodes，默认值是0，所以默认情况下，2 这个条件直接就不判断了。但是我们还可以继续看看判断Datanode活跃的代码。
   image
2. 跟进 getNumLiveDataNodes()，看到就一句代码
   image
3. 继续跟进 .getNumLiveDataNodes();，可以看到，判断Datanode是否活跃的主要代码其实就是 !isDatanodeDead(dn)，也就是说，不是死亡的 datanode就是活跃的
   image
4. 继续跟进 !isDatanodeDead(dn) ，可以看到就一句代码，此代码就是计算 datanode是否死亡的代码。node.getLastUpdateMonotonic() 就是最后一次心跳的时间 ，monotonicNow()就是当前时间，heartbeatExpireInterval是心跳过期间隔；
   所以计算公式就是：
   如果 当前时间 - 最后一次心跳时间 > 心跳过期间隔 那么就认为Datanode死亡了。
   image
5. 最后看看 heartbeatExpireInterval 是多少呢？
   heartbeatRecheckInterval 默认是5分钟， heartbeatIntervalSeconds默认是3秒，他们在配置文件里都有配置，具体代码就不跟了。
   image

4. 总结

到此：Namenode 安全模式的代码就分析完了。这里画个图简单的描述情况

image

点击这里查看原文地址