hadoop FSNamesystem中的recentInvalidateSets

今天早就回来了,然后偷懒了2个小时,现在才开始分析代码,之前在几篇文章里都有说将某些block加入到recentInvalidateSets,然后也没分析这个set具体的作用,以及后续的处理,今天就单独来说下他(看完代码才发现原来这么简单,其实应该在ReplicationMonitor中分析的,可惜当时太晚了没心思分析了)

分析之前先看下他的数据结构

Java代码      收藏代码
  1. //   
  2. // Keeps a Collection for every named machine containing   
  3. // blocks that have recently been invalidated and are thought to live   
  4. // on the machine in question.   
  5. // Mapping: StorageID -> ArrayList<Block>   
  6. //   
  7. private  Map<String, Collection<Block>> recentInvalidateSets =   
  8.   new  TreeMap<String, Collection<Block>>();  

 key是datanode的唯一标示StorageID  value是这个datanode上无效的block

之前的文章里已经说明了他的数据来源情况,今天只分析下对他的处理,对他的处理请求是在ReplicationMonitor这个后台任务线程中的computeInvalidateWork方法里执行的(实际方法是invalidateWorkForOneNode),在这个方法里会取出map里第一个datanode节点上所有无效的block,然后将这个block列表设置到表示这个datanode的DatanodeDescriptor对象的invalidateBlocks这个集合中,这个集合的数据结构如下:

Java代码      收藏代码
  1. /** A set of blocks to be invalidated by this datanode */   
  2.   private  Set<Block> invalidateBlocks =  new  TreeSet<Block>();  

 也就是说让datanode对象持有自身无效block列表,那么这个列表谁会关心呢,或者说什么时候会被用起来呢,追踪代码发现是datanode给namenode发送心跳信息时,namenode会依据自己保存的DatanodeDescriptor对象中invalidateBlocks这个集合来生成一个invalidate blocks的命令返回给datanode,同时将这些无效的block也给datanode,让datanode来处理这些无效的block。

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

猜你喜欢

转载自jlins-you.iteye.com/blog/1492320