`

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保护,因为并发量不大,所以这样用没什么问题的,和我自己在公司写的一个组件的思路是一致的。

 

 

分享到:
评论

相关推荐

    NameNode职责.pptx

    NameNode是Hadoop分布式文件系统HDFS的核心组件之一,负责维护文件系统的元数据。下面是NameNode的职责和相关知识点: NameNode的职责 NameNode是HDFS的中心节点,负责维护文件系统的命名空间。它的主要职责包括:...

    Hadoop Namenode性能诊断及优化

    2. **jstack+脚本**:通过jstack工具获取NameNode进程中的线程快照,并结合脚本自动化分析这些快照,寻找可能的死锁或阻塞情况。 3. **利用x86 PMU的Profiling工具**:利用Oprofile或Intel Vtune等工具对NameNode...

    Namenode瓶颈解决方案

    文件名“都是海量惹得祸 之 大家来聊Namenode瓶颈解决方案.pptx”表明这是一个关于Namenode问题的演讲或报告,可能详细阐述了大数据量对Namenode的影响,分析了问题的根源,并提供了具体的解决方案。 在实际解决...

    hadoop2.0 2个namenode 2个datanode 部署

    Hadoop 2.0 双 Namenode 双 Datanode 部署 Hadoop 是一个开源的大数据处理框架,它提供了分布式文件系统(HDFS)和Map/Reduce 计算框架。 在这个部署中,我们将使用 Hadoop 2.0 在两个 Ubuntu 服务器上部署双 ...

    HDFS中NameNode节点的配置、备份和恢复.doc

    HDFS 中 NameNode 节点的配置、备份和恢复 HDFS(Hadoop Distributed File System)是 Hadoop 生态系统中的分布式文件系统,它提供了高效、可靠、可扩展的文件存储解决方案。 NameNode 是 HDFS 集群中的中心服务器...

    namenode启动失败参考

    在Hadoop分布式文件系统(HDFS)中,Namenode是关键组件,它负责元数据管理,包括文件系统的命名空间和文件的块映射信息。当Namenode启动失败时,通常与fsimage和edits文件有关,这些文件是Namenode存储元数据的重要...

    NameNode机制.docx

    NameNode作为Hadoop分布式文件系统(HDFS)的核心组件之一,负责管理整个文件系统的命名空间以及客户端的文件访问。为了保证元数据的安全性和持久性,NameNode在运行过程中需要将元数据保存在内存中,并同时在磁盘中...

    Hadoop之NameNode Federation图文详解

    Hadoop之NameNode Federation图文详解 Hadoop的NameNode Federation是HDFS(Hadoop Distributed File System)中的一种架构设计,旨在解决NameNode的扩展性、隔离性和性能问题。本篇文章将对NameNode Federation的...

    namenode元数据管理机制

    hdfs的namenode的元数据管理机制,简要画出了元数据管理的流程分析

    Hadoop Namenode恢复

    Hadoop Namenode 是 Hadoop 分布式文件系统的核心组件之一,负责管理文件系统的命名空间。然而,在生产环境中,namenode 的崩溃可能会导致整个集群的不可用。因此,namenode 的恢复是非常重要的。本文将详细介绍 ...

    hadoop NameNode 源码解析

    Hadoop 的 NameNode 是 Hadoop 分布式文件系统(HDFS)的核心组件之一,负责管理文件系统的 namespace 和数据块的存储位置。在本文中,我们将深入探讨 Hadoop NameNode 的源码,了解其启动过程、配置加载、RPC ...

    hadoop namenode双机热备

    在IT行业中,高可用性是关键,特别是在大数据处理领域,Hadoop作为分布式计算框架,其NameNode节点的稳定性至关重要。"hadoop namenode双机热备"是为确保Hadoop集群持续运行而采取的一种重要策略,通过双机热备可以...

    11_尚硅谷大数据之HDFS_NameNode和SecondaryNameNode1

    在Hadoop大数据存储系统中,HDFS(Hadoop Distributed File System)是核心组件之一,用于分布式存储大量数据。NameNode是HDFS的核心节点,负责管理文件系统的元数据,包括文件和目录的命名空间以及文件的块映射信息...

    【HDFS篇08】NameNode故障处理1

    在分布式文件系统Hadoop的HDFS(Hadoop Distributed File System)中,NameNode是核心组件,负责元数据的管理,包括文件系统命名空间和文件块的映射信息。当NameNode发生故障时,数据的可用性和系统的稳定性都会受到...

    NameNode及SecondaryNameNode分析

    NameNode及SecondaryNameNode分析

    HDFS的概念-namenode和datanode.pdf

    《HDFS的概念——Namenode和Datanode详解》 Hadoop分布式文件系统(HDFS)是Apache Hadoop项目的核心组件,为大数据处理提供了高效、可靠的分布式存储解决方案。HDFS设计的目标是处理海量数据,其架构基于两个核心...

    (orc + snappy / zlib ) 多线程并行合并小文件工具类 (出自:flink自定义合并orc小文件处)

    小文件指的是大小相对较小的文件,它们在分布式系统中可能导致大量的数据块,增加NameNode的内存负担,降低I/O效率。为了解决这个问题,我们可以采用各种合并策略,其中一种是通过多线程并行合并小文件。本项目提供...

    【HDFS篇07】NameNode和SecondearyNameNode1

    HDFS(Hadoop Distributed File System)是Apache Hadoop项目的核心组件之一,它为大数据存储提供了一个可靠的、可扩展的分布式文件系统。在HDFS中,NameNode是主节点,负责管理文件系统的元数据,而...

    HDFS之NameNode分析

    大家都知道HDFS的架构由NameNode,SecondaryNameNode和DataNodes组成,其源码类图如下图所示:正如上图所示,NameNode和DataNode继承了很多的protocol用于彼此间的通信,其实nameNode还实现了...实现了ClientProtocol...

Global site tag (gtag.js) - Google Analytics