namenode任务线程之DecommissionManager$Monitor

因为ReplicationMonitor 依赖了其他4个所以这里先分析下DecommissionManager$Monitor

DecommissionManager主要是负责节点退役或者说节点停用，而Monitor负责定时来检测这些节点的退役状态，在DecommissionManager里其实也只有Monitor在真正执行功能，我们来看下Monitor的检测实现，

 

首先看下影响检测的几个参数

 

/** recheckInterval is how often namenode checks
  *  if a node has finished decommission
  */
 private
 
final
 
long
 recheckInterval;
 /** The number of decommission nodes to check for each interval */
 private
 
final
 
int
 numNodesPerCheck;
 /** firstkey can be initialized to anything. */
 private
 String firstkey = 
""
;

 因为需要检测全部的datanode，然后datanode又比较多，所以采用迭代的步长检测，例如每次只检测n个机器，下次检测时就是相对上次检测的的后n个机器，又为了保证检测的连续性，所以检测的数据构成一个环形数据结构，然后需要记录每次迭代的起始点，所以有个firstkey，然后环形数据结构由hadoop自己实现的CyclicIteration来提供（其实就是首尾数据相连）

 

看下检测的逻辑

1
：判断节点是否处于DECOMMISSION_INPROGRESS状态
2
：如果处于DECOMMISSION_INPROGRESS状态，则检测该节点上的所有数据块是否已经到了复制因子
3
：如果已经到了复制因子块的个数则说明这个节点上的所有块都是多余了，也就是说这个节点可以退役了，将节点状态设置为退役

 从上面的检测逻辑可以看出，其实就是为了确定是否这个节点上的数据块已经被完全复制过了到了复制因子，如果完全复制过了，那这个节点其实就没用了，所以就标示为退役了，主要起到一个审查的目的。

 

好上面有个状态常量

DECOMMISSION_INPROGRESS

那这个值是谁设置的呢，一般在什么情况会触发呢，主要是DFSAdmiin负责触发

 

DFSAdmin的 -refreshNodes 命令或者说传递这个命令参数的其他调用者例如Balancer ，DFSck等。
refreshNode会依据exclude文件里配置的ip来更新node节点的状态，例如这里是调用setDECOMMISSION_INPROGRESS（datanode）

 更多信息请查看 java进阶网 http://www.javady.com