hadoop FSNamesystem中的recentInvalidateSets
今天早就回来了，然后偷懒了2个小时，现在才开始分析代码，之前在几篇文章里都有说将某些block加入到recentInvalidateSets，然后也没分析这个set具体的作用，以及后续的处理，今天就单独来说下他（看完代码才发现原来这么简单，其实应该在ReplicationMonitor中分析的，可惜当时太晚了没心思分析了）分析之前先看下他的数据结构
Java代码
[*]//
[*]// Keeps a Collection for every named machine containing
[*]// blocks that have recently been invalidated and are thought to live
[*]// on the machine in question.
[*]// Mapping: StorageID -> ArrayList<Block>
[*]//
[*]private Map<String, Collection<Block>> recentInvalidateSets =
[*] new TreeMap<String, Collection<Block>>();
key是datanode的唯一标示StorageID value是这个datanode上无效的block
之前的文章里已经说明了他的数据来源情况，今天只分析下对他的处理，对他的处理请求是在ReplicationMonitor这个后台任务线程中的computeInvalidateWork方法里执行的（实际方法是invalidateWorkForOneNode），在这个方法里会取出map里第一个datanode节点上所有无效的block，然后将这个block列表设置到表示这个datanode的DatanodeDescriptor对象的invalidateBlocks这个集合中，这个集合的数据结构如下：
Java代码
[*]/** A set of blocks to be invalidated by this datanode */
[*] 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
页:
[1]