zoukankan      html  css  js  c++  java
  • HBase——HMaster启动之一(HMaster的构建)

      首先,让我们来到HMaster的main方法。我们今天的流程就从这里开始。
      我们需要注意,下图所示的tool的类型就是HMasterCommandLine。
      接下来,让我们来到HMasterCommandLine.run方法
      在HMasterCommandLine.startMaster方法开始,有判断LocalHBaseCluster.isLocal(conf),也就是我们在hbase-site.xml中是否配置了hbase.cluster.distributed(默认为false)。这里我们只分析值为true的情形。其主要通过方法如下图所示:
      在构建HMaster的过程中,最主要的又两个方法,其中一个是下图所示调用了其父类HRegionServer的构造方法,还有一个在下面的第二章图中有显示,也就是构建了ActiveMasterManager。其中ActiveMasterManager主要是用来处理master端与master选举相关的一切,我们简单略过。只是介绍HRegionServer的构造方法。
      HRegionServer的构造方法也比较长,下面通过三张图来展示:以下分别用RSG1、RSG2、RSG3来表示。
      首先我们来看RSG1中的setupNetty,如下图所示:
      接下来让我们来到NettyEventLoopGroupConfig的构造方法,如下图所示,在构造方法内部,构造了Netty中的eventLoopGroup,为后面的rpc调用准备条件。
      关于RSG1中的Sleeper,我们这里留一个疑问,等到HMaster真正运行的时候,他的威力才显示出来。而这个sleeper造成困扰小编很久的疑问。
      接下来,让我们来到RSG2的,这是HMaster或HRegionServer在构造的重量级方法。由于我们这里只介绍HMaster,因此来到HMaster覆写的createRpcServices中,显然,在这里构建了MasterRpcServices。  我们可以看到,HMaster在构造时调用了其父类的构造方法RSRpcServices。
      接下来,我们来到RSRpcServices构造方法的主体,下图将比较关键的地方框选的出来。在第一个框中,获取了即将构建的rpcServer的ip与端口(默认为16000)。在第二个框中构建了NettyRpcServer(注意,这框中的rpcSchedulerFactory其类型为SimpleRpcSchedulerFactory)。
      然后,我们来到MasterRpcServices.createRpcServer,如下图所示,在这里主要构建了SimpleRpcScheduler。上面我们已经说到rpcSchedulerFactory类型为SimpleRpcSchedulerFactory。因此,在这里调用的方法是SimpleRpcSchedulertory.create。也就是调用了SimpleRpcScheduler的构造方法。由于SimpleRpcScheduler比较重要,我们在下图就略作介绍。
      来到SimpleRpcScheduler的构造方法。在这里主要构建了下面三个RpcExecutor,而这三个RpcExecutor就是以后用来处理客户端请求的Executor。这里只是这三个Executor的构建,在后面的启动流程中,仍然会提到。
      RpcExecutor的内容先告一段落。接下来, 让我们来到NettyRpcServer的构造方法中,由于上一步骤中使用的rpcSchedulerFactory类型为SimpleRpcSchedulerFactory,因此,这里传入的scheduler类型为SimpleRpcScheduler,也就是上面所说的。
      在NettyRpcServer的构造方法中,首先调用了其父类的构造方法,其中值得留意的是将传入的scheduler保存到了成员变量中,其它初始化的内容我们这里就不赘述了。然后来到第二个框中的内容,这里的getEventLoopGroupConfig获得的对象正是HRegionServer在构造一开始调用setupNetty获得的。忘记的同学可以看看往上面翻翻。
      接下来,在第三个框中,熟悉netty的同学可能就很清楚了,在这里构造了netty的服务端对象,最后,绑定了服务端端口并开始监听。
      在这里需要关注下面的一个方法createNettyRpcServerPreambleHandler。在这个方法中创建了NettyRpcServerPreambleHandler,而这个handler也就是我将要在下一节介绍的完整rpc流程中服务端处理的第一个Handler。这里只是简单提一下,希望各位同学有一点印象。
      看到这里,大家可以缓一口气,比较主要的服务端监听已经开始了。但是,这并不意味着HMaster就可以处理HRegionServer或客户端发送来的请求了。这里先留一个小的疑问。在后面的内容中,我将会为大家一一道来。接下来的内容依然很多,要往下读的同学需要鼓足勇气了。
      上面已经为各位同学介绍了RSG2中的createRpcServices,下面简单介绍一下RSG2中的initializeFileSystem方法。在这里初始化了两个HFileSystem。
      下面,来到RSG3中ZKWatcher的构造方法,如下图所示。其中,首先获取到配置中的zookeeper信息,然后封装了hbase中存储在ZK中的路径信息,接着,通过ZKUtil.connect构建了一个RecoverableZooKeeper对象,而在RecoverableZooKeeper的构造方法中创建了与ZK的连接。最后,将刚刚封装好的hbase路径在ZK上创建。
      本节另外一个比较重要的方法就是RSG3中的rpcServices.start,而我在上面抛出的疑问也将在这里解答。
      来到RSRpcServices.start方法,由于我并没有配置Authorization的有关信息,因此,在这里,主要调用了rpcServer.start。还记得在上面创建的rpcServer的类型吗。没错,就是在上面通过反射方式创建的NettyRpcServer。
      下面,来到NettyRpcServer.start方法。有安全相关的认证在这里先跳过,直接来到scheduler.start。我相信大家可能已经忘记了这里的scheduler的类型。往上面翻一翻就可以知道,这里的scheduler类型为SimpleRpcScheduler。
      来到SimpleRpcScheduler.start。各位同学时候还记得在这里的各个executor的类型,没错,他们的类型都是FastPathBalancedQueueRpcExecutor,下面我就分析一下其中start的奥秘。下面所框选的内容都比较关键,有余力的同学可以看一下,在后面的章节中我也会提到。  这里的RpcExecutor实际类型为FastPathBalancedQueueRpcExecutor。
      因而,来到FastPathBalancedQueueRpcExecutor,可以看到,返回的对象类型为FastPathHandler。在构造好FastPathHandler对象之后,调用了start方法。FastPathHandler继承自Handler。再往下看。  来到Handler类,看到其继承自Thread,并且覆写了Thread的run方法。也就是说,在上面调用start方法的时候,这里的run方法开始运行。由于Handler的实际类型为FastPathHandler,因此,在真正运行时,下图调用的getCallRunner为FastPathHandler.getCallRunner。比较关心的同学可以自己看一下。在这一节重点并不是这里,就点到为止了。  到现在为止,rpcServices的启动完成了,并且HMaster就可以处理HRegionServer或客户端发送来的请求了。各位同学可能还不清楚为什么。我在这里通过下面的图来简单介绍一下。客户端请求到服务端后,来到这里,将通过调用scheduler.dispatch,这里的sceduler也就是我在前面提到的SimpleRpcScheduler。由于刚刚handler已经启动完成,所有dispath后的所有请求,都可以由handler处理,而在上面,handler还没有启动,所以还没有办法处理。我在上面抛出的疑问也就解决了。至于以后的流程,我将在下一节详细介绍,欢迎大家关注。
      在RSG3中,然后创建了ChoreService。很多同学可能会对ChoreService不太清楚。其实ChoreService就是对很多继承自ScheduledChore的周期性调用。在ChoreService内部有一个周期性调度线程池ScheduledThreadPoolExecutor。在实例化时其真正类型一般是JitterScheduledThreadPoolExecutorImpl。而ScheduledChore是通过ChoreService调度激活的任务。ScheduledChore在ChoreService中调度运行时会与ChoreService中其他ScheduledChores竞争访问ChoreService线程池中的线程。
      接着创建了ExecutorService,注意这里的并非java中的ExecutorService,而是org.apache.hadoop.hbase.executor.ExecutorService。后面在HMaster调用startServiceThreads时会用到。
    到此,HMaster的构建完成了。

  • 相关阅读:
    二进制位运算
    Leetcode 373. Find K Pairs with Smallest Sums
    priority_queue的用法
    Leetcode 110. Balanced Binary Tree
    Leetcode 104. Maximum Depth of Binary Tree
    Leetcode 111. Minimum Depth of Binary Tree
    Leetcode 64. Minimum Path Sum
    Leetcode 63. Unique Paths II
    经典的递归练习
    案例:java中的基本排序
  • 原文地址:https://www.cnblogs.com/letsfly/p/9975964.html
Copyright © 2011-2022 走看看