namenode任务线程之PendingReplicationMonitor

这里描述下PendingReplicationMonitor 这个后台线程的任务

 

PendingReplicationBlocks$PendingReplicationMonitor

 

首先来看下PendingReplicationBlocks 这个类的作用

看下java doc里的类注释说明如下：

 

/***************************************************
 * PendingReplicationBlocks does the bookkeeping of all
 * blocks that are getting replicated.
 *
 * It does the following:
 * 1)  record blocks that are getting replicated at this instant.
 * 2)  a coarse grain timer to track age of replication request
 * 3)  a thread that periodically identifies replication-requests
 *     that never made it.
 *
 ***************************************************/

 这个类主要是记录所有的block复制请求，并内部来定期检测那些还没做完的请求。

 这个类针对复制请求提供如下接口：

 

  
/**
   * Add a block to the list of pending Replications
   */
  void
 add(Block block, 
int
 numReplicas)


  /**
   * One replication request for this block has finished.
   * Decrement the number of pending replication requests
   * for this block.
   */
  void
 remove(Block block)


/**
   * How many copies of this block is pending replication?
   */
  int
 getNumReplicas(Block block)

 所有来的请求都会保存到

Map<Block, PendingBlockInfo> pendingReplications  数据结构中

 

那么到底是谁把复制请求发送过来的呢，追踪一下查到了是

FSNamesystem$ReplicationMonitor

 这个后台任务线程发起的，好吧这个我会在后面的文章里详细说明的，我们只需要知道来源就好了。

 

 内部定期检测block复制请求是否完成的工作就交给了PendingReplicationMonitor

 那么有个疑问多长时间检测比较合适呢，看下java doc里的注释

//
// It might take anywhere between 5 to 10 minutes before
// a request is timed out.
//
private
 
long
 timeout = 
5
 * 
60
 * 
1000
;                          
//认为1次数据复制的时间最多是5分钟
private
 
long
 defaultRecheckInterval = 
5
 * 
60
 * 
1000
;  
//间隔时间为5分钟（感觉这个值有点大了，没有计算大家的请求到达率）

 这里检测间隔竟然不是可以调配的！！

 

  好了看下检测的逻辑：  通过比较 当前时间 和 原始块请求产生的时间 + timeout和 来判断是否还没完成复制，如果没有完成复制则将那些块放入超时块列表，对应的数据结构是

 

ArrayList<Block> timedOutItems;

 针对这个列表提供如下的接口

/**
 * Returns a list of blocks that have timed out their
 * replication requests. Returns null if no blocks have
 * timed out.
 */
Block[] getTimedOutBlocks()

 好这次再看看谁关心这个数据    再次追踪到了 又是

FSNamesystem$ReplicationMonitor

   看来这个线程算是复制block的小弟了，主管还是

ReplicationMonitor

这个下次在分析他。

 

从整个代码结构看，后台任务线程运作的方式为

Thread A ------>   ShareStatusContainer <------------ Thread B  然后对ShareStatusContainer采用synchronized保护，因为并发量不大，所以这样用没什么问题的，和我自己在公司写的一个组件的思路是一致的。

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