紧接着上一节HMaster的构建完成。接下来会调用HMaster调用master.start(),master.join()。
由HMaster的继承关系,很明显,他是Runnable的子类。也就是说,在调用其start方法时,run方法被调用。
下面,让我们来到HMaster.run方法。这里的涉及到多线程编程。一方面HMaster所在线程调用了super.run方法。另一方面另外启动了一个daemon线程用于调用startActiveMasterManager方法。很多同学在这里可能就迷惑了,到底该先分析哪个呢,我在刚开始看的时候也比较懵逼,后来多分析了几次发现,殊途同归,先分析哪个都无所谓。下面,我先从简单的开始介绍。
让我们来到super.run的调用。来到这里一看,内容很多,各位同学不需要慌,让我们再进入preRegistrationInitialization一探究竟。
来到preRegistrationInitialization,各位同学可能有所迷惑,为什么比较关键的方法有三个,而我在这里之框选了一个呢。原因很简单,在HMaster启动期间,他还运行不到下面去。
接着,让我们一探究竟。看了两个block方法,各位同学可能以为是在这里阻塞的,然而并不是,真正的等待是在下图框选的waitForMasterActive。
来到waitForMasterActive(由于在这里我们研究的是HMaster,因此,这里的方法应该是HMaster.waitForMasterActive)。这个方法虽然比较短,确实困扰了我很久的一个地方。下图框选的地方获得的默认值为false,而isStopped与isAborted的获得的初始值都是false。因此,HMaster在启动时,包括启动后,都一直在这里轮询等待。因为启动后只是将activeMaster置位false。在tablesOnMaster默认值为false的情况下,并没有任何作用。也就是说只有后面的两个值发生变动后,这种等待才会被打破。分析到这里,各位同学应该可以安心的分析那个守护线程了。
让我们来到HMaster.startActiveMasterManager方法中,首先通过调用activeMasterManager.blockUntilBecomingActiveMaster确定当前Master为ActiveMaster,然后再调用finishActiveMasterInitialization方法。这里我们只分析ActiveMaster的流程,并不介绍StandyMaster。在blockUntilBecomingActiveMaster方法中的调用并不是很难,感兴趣的同学可以简单。在activeMasterManager.blockUntilBecomingActiveMaster。这里我们把重点放在finishActiveMasterInitialization。
接下来让我们来到finishActiveMasterInitialization方法。
这个方法是出奇的长,在这里,我们还是按照一张张的来介绍,以避免大家到后面会忘记前面的。 首先我们分析第一个方法initializeMemStoreChunkCreator,其实这里只是初始化了
来到ChunkCreator的构造方法,我们可以看到其主要调用了initializePools方法
在initializePool方法中,主要构建了MemStoreChunkPool,并且将其加入heapMemoryManager的管理之中。而在构建MemStoreChunkPool的过程中,创建了Chunk,并将其放入reclaimedChunks中,初始化并开始周期调用统计线程StatisticsThread,将其内存数据打印出来。这里设计到HBase的内存管理,我将在后续的章节中专门拿出一讲来为大家讲解。这里就介绍到这。
接着来到MasterFileSystem的构造方法中,这里主要获得了fs与walFs。
接下来,让我们来到createServerManager方法中,在这里首先构建了clusterConnection对象,其中主要构建了ShortCircuitingClusterConnection与MetaTableLocator。这里简单略过,详细内容请看我的另外一篇博文《HBase之setupClusterConnection流程》。然后构造了ServerManager,他就是HMaster用于管理region servers信息的类。
再接下来,来到createProcedureExecutor,这是一个重量级的方法。
让我们首先来到MasterProcedureEnv的构造方法,这个构造方法看似简单,却同时构造了两个重要的对象。RSProcedureDispatcher、MasterProcedureScheduler。其中的RSProcedureDispatcher负责HMaster向RegionServer的Procedure调用,而MasterProcedureScheduler负责的是Master自身的Procedure的调用。
需要注意的是,在MasterProcedureScheduler中有几个队列的成员变量,他们的作用就是保存将要调用procedure,然后由具体线程调用。
接下来是WALProcedureStore,这里主要传入了一个LeaseRecovery对象,而他的实际类型是MasterProcedureEnv.WALStoreLeaseRecovery,他的主要作用是对hdfs的文件恢复租约。
在ProcedureExecutor的构造方法中只是对其成员变量的赋值,并没有什么比较重要的方法。不过,在这里我们需要记住,在这里传入的store类型为WALProcedureStore,scheduler类型为MasterProcedureScheduler。
接下来来到WALProcedureStore.start方法。在这里,根据传入的线程数初始化了Slot数量,并且启动WALProcedureStoreSyncThread线程用于调用syncLoop方法。这里就简单略过,我们先继续后面的流程。
下面,来到ProcedureExecutor.init方法。这里将WorkerThread,添加到workerThread成员变量中。接着调用store.recoverLease,恢复相关文件的租约。然后调用scheduler.start,将scheduler中的running置位true。 这里简单看一下WorkThread中的run方法。这里的流程在我的博文《hbase之InitMetaProcedure流程》中有相关介绍,感兴趣的大家可以去看一下。
接下来来到finishActiveMasterInitialization的第二张图。
首先创建了AssignmentManager,AssignmentManager的作用就是用来操作assign/unassign。然后调用了AssignmentManager.start方法。关于AssignmentManager的相关调用我在博文《HBase之AssignmentManager相关调用》中有介绍,感兴趣的同学可以去看一下。接下来构造并调用了RegionServerTracker,用于通过ZK跟踪在线RegionServers。
然后调用了initializeZKBasedSystemTrackers方法,在这里初始化了所有基于ZK的系统跟踪器。尽管如此,还是有些方法值得我们探究。首先介绍各种Tracker,这些都是直接或间接继承自ZKListener,或者将传入的ZK保存到自己的成员变量中用来实现对自己所在ZK目录中状态的监听。
然后来到LoadBalancerFactory.getLoadBalancer方法,这里调用ReflectionUtils.newInstance通过反射创建了StochasticLoadBalancer,同时由于StochasticLoadBalancer实现了Configurable接口。因此在通过反射创建了StochasticLoadBalancer,紧接着变调用了setConf方法。在StochasticLoadBalancer.setConf中调用了构造了各种CostFunction。在这里我们简单略过。
接下来来到方法的后面,这里构建了SnapshotManager、MasterFlushTableProcedureManager(二者都继承自抽象类ProcedureManagerHost)并且注册到创建的MasterProcedureManagerHost对象中。接着调用了MasterProcedureManagerHost.initialize,调用了刚刚注册进来的两个对象initialize方法。
接下来来到finishActiveMasterInitialization的下一张图。如果已经不是第一次调用,那么就不会调用框二中所选的内容,不过,感兴趣的同学可以去看我的博客《hbase之InitMetaProcedure流程》。这里我们只介绍框一与框三中的内容。
来到HMaster.startServiceThreads。这里的executorService大家可能已经忘记了,他是在HMaster构造时实例化的(具体是在HMaster的父类HRegionServer构造的最后)。通过调用executorService.startExecutorService,ExecutorType的类型与最大线程数量传入ExecutorService.startExecutorService,构造了相应名称的线程池,并且将其置于ExecutorService的成员变量executorMap的管理之下。接下来我们简单介绍一下getChoreService().scheduleChore。这是ScheduledChore调用的通用方式,通过getChoreService获取初始化的成员变量choreService(同样在HMaster的父类HRegionServer构造的最后实例化的),然后调用其scheduleChore方法,在上面我已经讲过了,这里就不再赘述了。
接着调用waitForRegionServers等待RegionServer的注册。关于HMaster与HRegionServer的交互流程我在以后的章节中会介绍到。接下来调用waitUntilMetaOnline,等待hbase:meta上线并且可读。以为后面assignmentManager.joinCluster中loadMeta做准备。
接下来,我们首先来到assignmentManager.joinCluster
在loadMeta中,主要用于载入hbase:meta的各个Region,并且将其加入到regionStates的管理中。接下来调用processOfflineRegions,当前保存在AssignmentManager.regionStates中,其状态OFFLINE的Regions。然后将成员变量ritChore加入到ProcedureExecutor的timeoutExecutor中。
接下来调用了TableStateManager.start,将当前的表都置于TableStateManager的管理之中。
下面框选中的内容虽然多,但是,我们只是简单介绍。因为这里已经不是很主要的流程了。首先是几个ScheduledChore的子类构建并调用。接着,调用ServerManager.startChore其主要讲FlushedSequenceIdFlusher这个ScheduledChore构建并开始调用。然后,调用了initClusterSchemaService、cpHost.preMasterInitialization。最后,将三个ConfigurationObserver注册到configurationManager中。
来到FAMI中的最后一张图,这里我们只是引出,关于其中具体的流程,我们将在后面意义道来。在后面主要介绍initMobCleaner。
下图首先构建了ExpiredMobFileCleanerChore(这个ScheduledChore用于定期删除过期的mob文件),然后将其加入到choreService中并启动。紧接着构建并启动了MobCompactionChore,这个ScheduledChore用于定期压缩以合并小的mob文件。然后构建了MasterMobCompactionThread。
至此,HMaster的启动流程就完成了,感谢大家内心观看。说实话,不仅各位看的辛苦,小编我写的也很辛苦,所以,留下你的赞,小编更有动力发表更好的文章。
学完这一节,很多同学可能会对netty的原理想要有比较深入的了解。请各位同学不要着急,在介绍完HBase中比较重要的流程,小编就会为大家带来netty的深入应用以及源码剖析。请大家持续关注。