HBase源码:HRegionServer启动过程

版本:HBase 0.94.15-cdh4.7.0

关于HMaster启动过程,请参考HBase源码:HMaster启动过程。先启动了HMaster之后,再启动HRegionServer。

运行HRegionServerStarter类启动HRegionServer:

package my.test.start;

import org.apache.hadoop.hbase.regionserver.HRegionServer;

public class HRegionServerStarter {

    public static void main(String[] args) throws Exception {
        //new HMasterStarter.ZookeeperThread().start();

        HRegionServer.main(new String[] { "start" });
    }

}

同样参考HBase源码:HMaster启动过程,运行HRegionServer.main方法,会通过反射创建一个HRegionServer实例,然后调用其run方法。

HRegionServer类继承关系如下:

构造方法

主要包括:

  • 设置服务端HConnection重试次数
  • 检查压缩编码,通过hbase.regionserver.codecs可以配置编码类,一一检测,判断是否支持其压缩算法。
  • 获取useHBaseChecksum值,是否开启hbase checksum校验
  • 获取hbase.regionserver.separate.hlog.for.meta参数值
  • 获取客户端重复次数
  • 获取threadWakeFrequency值
  • 获取hbase.regionserver.msginterval
  • 创建Sleeper对象,用于周期性休眠线程
  • 获取最大扫描结果集大小,hbase.client.scanner.max.result.size,默认无穷大
  • 获取hbase.regionserver.numregionstoreport
  • 获取rpctimeout值,hbase.rpc.timeout,默认60000
  • 获取主机名和绑定的ip和端口,端口默认为60020
  • 创建rpcServer
  • zk授权登录和hbase授权
  • 创建RegionServerAccounting
  • 创建CacheConfig

run方法

  • preRegistrationInitialization

    • initializeZooKeeper,此方法不会创建任何节点 - 创建ZooKeeperWatcher - 创建MasterAddressTracker 并等到”/hbase/master”节点有数据为止 - 创建ClusterStatusTracker 并等到”/hbase/shutdown”节点有数据为止 - 创建CatalogTracker 不做任何等待 - 创建RegionServerSnapshotManager
    • 设置集群id
    • 初始化线程:initializeThreads - 创建 cacheFlusher - 创建 compactSplitThread - 创建 compactionChecker - 创建 periodicFlusher - 创建 healthCheckChore - 创建 Leases - 判断是否启动 HRegionThriftServer
    • 参数hbase.regionserver.nbreservationblocks默认为4,默认会预留20M(每个5M,20M = 4*5M)的内存防止OOM
    • 初始化rpcEngine = HBaseRPC.getProtocolEngine(conf)
  • reportForDuty,轮询,向汇报master自己已经启动
    • getMaster(),取出”/hbase/master”节点中的数据,构造一个master的ServerName,然后基于此生成一个HMasterRegionInterface接口的代理,此代理用于调用master的方法
    • regionServerStartup
  • 当轮询结果不为空时,调用handleReportForDutyResponse - regionServerStartup会返回来一个MapWritable,这个MapWritable有三个值,这三个key的值会覆盖rs原有的conf: - “hbase.regionserver.hostname.seen.by.master” = master为rs重新定义的hostname(通常跟rs的InetSocketAddress.getHostName一样)rs会用它重新得到serverNameFromMasterPOV - “fs.default.name” = “file:///” - “hbase.rootdir” = “file:///E:/hbase/tmp” - 查看conf中是否有”mapred.task.id”,没有就自动设一个(格式: “hb_rs_“+serverNameFromMasterPOV),例如: hb_rs_localhost,60050,1323525314060 - createMyEphemeralNode:在zk中建立 短暂节点”/hbase/rs/localhost,60050,1323525314060”,也就是把当前rs的serverNameFromMasterPOV(为null的话用rs的InetSocketAddress、port、startcode构建新的ServerName)放到/hbase/rs节点下,”/hbase/rs/localhost,60050,1323525314060”节点没有数据 - 设置fs.defaultFS值为hbase.rootdir的值 - 生成一个只读的FSTableDescriptors - 调用setupWALAndReplication - 初始化 hlog、metrics、dynamicMetrics、rsHost - 调用startServiceThreads启动服务线程 - 启动一些ExecutorService - 启动hlogRoller - 启动cacheFlusher - 启动compactionChecker - 启动healthCheckChore - 启动periodicFlusher - leases.start() - 启动jetty的infoServer,默认端口为60030 - 启动复制相关打的一些handler:replicationSourceHandler、replicationSourceHandler、replicationSinkHandler - rpcServer启动 - 创建并启动SplitLogWorker
  • registerMBean
  • snapshotManager启动快照服务
  • 在master上注册之后,进入运行模式,周期性(msgInterval默认3妙)调用doMetrics,tryRegionServerReport
    • isHealthy健康检查,只要Leases、MemStoreFlusher、LogRoller、periodicFlusher、CompactionChecker有一个线程退出,rs就停止
    • doMetrics
    • tryRegionServerReport向master汇报rs的负载HServerLoad
  • shutdown之后的一些操作
    • unregisterMBean - 停掉thriftServer、leases、rpcServer、splitLogWorker、infoServer、cacheConfig

      • 中断一些线程:cacheFlusher、compactSplitThread、hlogRoller、metaHLogRoller、compactionChecker、healthCheckChore
    • 停掉napshotManager
    • 停掉 catalogTracker、compactSplitThread
    • 等待所有region关闭
    • 关闭wal
    • 删除zk上的一些临时节点,zooKeeper关闭

总结一下,HRegionServer主要干以下事情:

  • 在zk上注册自己,表明自己上线了
  • 跟master汇报
  • 设置wal和复制
  • 注册协作器RegionServerCoprocessorHost
  • 启动hlogRoller
  • 定期刷新memstore
  • 定期检测是否需要压缩合并
  • 启动租约
  • 启动jetty的infoserver
  • 创建SplitLogWorker,用于拆分HLog
  • 快照管理

总结

HRegionServer类中创建了一些对象:

  • HBaseServer:处理客户端请求
  • Leases:租约
  • InfoServer:Jetty服务器
  • RegionServerMetrics:
  • RegionServerDynamicMetrics:
  • CompactSplitThread:合并文件线程
  • MemStoreFlusher:刷新memstore线程
  • 两个Chore:compactionChecker、periodicFlusher
  • 两个LogRoller:hlogRoller、metaHLogRoller
  • MasterAddressTracker:跟踪master地址
  • CatalogTracker:跟踪-ROOT-和.META.表
  • ClusterStatusTracker:跟踪集群状态
  • SplitLogWorker:拆分log
  • Sleeper:
  • ExecutorService:
  • ReplicationSourceService和ReplicationSinkService:复制服务
  • RegionServerAccounting:
  • CacheConfig:缓存配置和block
  • RegionServerCoprocessorHost:RegionServer协作器
  • HealthCheckChore:健康检查
时间: 2024-09-19 08:54:05

HBase源码:HRegionServer启动过程的相关文章

Nginx学习笔记(六) 源码分析&启动过程

涉及到的基本函数 源码: 1 /* 2 * Copyright (C) Igor Sysoev 3 * Copyright (C) Nginx, Inc. 4 */ 5 6 7 #include <ngx_config.h> 8 #include <ngx_core.h> 9 #include <nginx.h> 10 11 12 static ngx_int_t ngx_add_inherited_sockets(ngx_cycle_t *cycle); 13 sta

HBase源码分析之HRegionServer上MemStore的flush处理流程(一)

        在<HBase源码分析之HRegion上MemStore的flsuh流程(一)>.<HBase源码分析之HRegion上MemStore的flsuh流程(二)>等文中,我们介绍了HRegion上Memstore flush的主体流程和主要细节.但是,HRegion只是HBase表中按照行的方向对一片连续的数据区域的抽象,它并不能对外提供单独的服务,供客户端或者HBase其它实体调用.而HRegion上MemStore的flush还是要通过HRegionServer来

HBase源码分析之HRegionServer上MemStore的flush处理流程(二)

        继上篇文章<HBase源码分析之HRegionServer上MemStore的flush处理流程(一)>遗留的问题之后,本文我们接着研究HRegionServer上MemStore的flush处理流程,重点讲述下如何选择一个HRegion进行flush以缓解MemStore压力,还有HRegion的flush是如何发起的.         我们先来看下第一个问题:如何选择一个HRegion进行flush以缓解MemStore压力.上文中我们讲到过flush处理线程如果从flus

HBase源码分析之compact请求发起时机、判断条件等详情(一)

        一般说来,任何一个比较复杂的分布式系统,针对能够使得其性能得到大幅提升的某一内部处理流程,必然有一个定期检查机制,使得该流程在满足一定条件的情况下,能够自发的进行,这样才能够很好的体现出复杂系统的自我适应与自我调节能力.我们知道,HBase内部的compact处理流程是为了解决MemStore Flush之后,文件数目太多,导致读数据性能大大下降的一种自我调节手段,它会将文件按照某种策略进行合并,大大提升HBase的数据读性能.那么,基于我刚才的陈述,compact流程是否有一个

hbase源码系列(十二)Get、Scan在服务端是如何处理?

继上一篇讲了Put和Delete之后,这一篇我们讲Get和Scan, 因为我发现这两个操作几乎是一样的过程,就像之前的Put和Delete一样,上一篇我本来只打算写Put的,结果发现Delete也可以走这个过程,所以就一起写了. Get 我们打开HRegionServer找到get方法.Get的方法处理分两种,设置了ClosestRowBefore和没有设置的,一般来讲,我们都是知道了明确的rowkey,不太会设置这个参数,它默认是false的. if (get.hasClosestRowBef

HBase源码分析之MemStore的flush发起时机、判断条件等详情(二)

        在<HBase源码分析之MemStore的flush发起时机.判断条件等详情>一文中,我们详细介绍了MemStore flush的发起时机.判断条件等详情,主要是两类操作,一是会引起MemStore数据大小变化的Put.Delete.Append.Increment等操作,二是会引起HRegion变化的诸如Regin的分裂.合并以及做快照时的复制拷贝等,同样会触发MemStore的flush流程.同时,在<HBase源码分析之compact请求发起时机.判断条件等详情(一

HBase源码分析之HRegion上MemStore的flsuh流程(二)

        继上篇<HBase源码分析之HRegion上MemStore的flsuh流程(一)>之后,我们继续分析下HRegion上MemStore flush的核心方法internalFlushcache(),它的主要流程如图所示:         其中,internalFlushcache()方法的代码如下: /** * Flush the memstore. Flushing the memstore is a little tricky. We have a lot of upda

HBase源码分析之HRegion上compact流程分析(三)

        在<HBase源码分析之HRegion上compact流程分析(二)>一文中,我们没有讲解真正执行合并的CompactionContext的compact()方法.现在我们来分析下它的具体实现.         首先,CompactionContext表示合并的上下文信息,它只是一个抽象类,其compact()并没有实现,代码如下: /** * Runs the compaction based on current selection. select/forceSelect

HBase源码分析之MemStore的flush发起时机、判断条件等详情

        前面的几篇文章,我们详细介绍了HBase中HRegion上MemStore的flsuh流程,以及HRegionServer上MemStore的flush处理流程.那么,flush到底是在什么情况下触发的呢?本文我们将详细探究下HBase中MemStore的flush流程的发起时机,看看到底都有哪些操作,或者哪些后台服务进程会触发MemStore的flush.         首先,在<HBase源码分析之HRegionServer上MemStore的flush处理流程(一)>和