本文基于hbase-1.3.0源码

1. HMaster启动

HMaster继承了HRegionServer，实现了MasterServices。

1. HMaster继承了HRegionSever,前文提到HRegionServer初始化后通过run()方法完成HRegionServer提供的各类服务的启动，但是HMaster重写了run()方法，不再启动这些服务，也就是HMaster不充当HRegionServer的角色，不负责用户表数据的读写，split，compact这些工作。

2. HMaster实现了MasterServices，MasterServices定义了master提供的服务：管理table schema，指派region由region server管理. 下面是一些HMaster的重要成员，它们也代表master所做的事情：

   //用来在几个HMaster之间选择一个主HMaster
   1. private final ActiveMasterManager activeMasterManager;
   //监听zk的/hbase/draining节点，drainging节点里存放迁移的region server
   2. private DrainingServerTracker drainingServerTracker;
   //监听zk /hbase/balancer节点的data，获知是否容许对region做balance
   //允许balance会根据一定的策略使得每个region server管理的region趋于平衡
   3. LoadBalancerTracker loadBalancerTracker;
   //监听 zk /hbase/switch/split 和/hbase/switch/merge节点
   4. private SplitOrMergeTracker splitOrMergeTracker;
   //监听 zk /hbase/normalizer节点，用于检查开启或关闭normalizer
   5. private RegionNormalizerTracker regionNormalizerTracker;
   //管理region server打开关闭，充当admin角色要求region server open、split、merge region等等
   6. volatile ServerManager serverManager;
   //它监听/hbase/region-in-transition主要用来处理指派region到region server的。还被hmaster用来指派meta table的region
   AssignmentManager assignmentManager;
   // 周期性检查cluster上所有region server，检查是否需要做region server的负载均衡
   7. private BalancerChore balancerChore;
   //如果开启normalizer，周期性检查是否要做normalizer，normalizer用于对过大的region做split，以及小的region做merge。
   8. private RegionNormalizerChore normalizerChore;
   //snapshot管理器，不是很了解，hbase 对表做snapshot不是记下所有数据，而只是记录当前table的一些状态（例如wal的max sequence id）。
   9. SnapshotManager snapshotManager;
   

1.2 HMaster构造函数

1. 创建ActiveMasterManager用来选主HMaster。

2. 在HMaster构造函数里启动内嵌的JettyServer，默认监听”0.0.0.0:16010″端口，可以通过web的方式访问master的信息。

3. 调用startActiveMasterManager(), 在这个方法里选master，当自己当选master之后，完成master的初始化，否则会一直阻塞直到master挂了，再选新的，如此循环。这个方法做的事情如下:

   1. 将当前server放到zk的/hbase/backup-masters下面，这下面所有备份master，一旦自己当选，会将自己从这个里面移除。
   2. 启动一个新的线程，在新线程里使用尝试将zk /hbase/master设置成自己，成功的话表示当选master，返回；失败则表示有其他的master，会一直阻塞。
   

上面3中当前hmaster没有成为主master会一直阻塞，下面说说当前hmaster称为主master之后的初始化工作，此时调用HMaster#finishActiveMasterInitialization初始化HMaster的服务：

HMaster#finishActiveMasterInitialization主要完成一下的一些服务的创建：

1. 创建fileSystemManager，包装hdfs。

2. 调用this.tableDescriptors.getAll(); 加载table的schema信息，并缓存。

3. 创建servermanager，管理所有hregion server的。

4. 调用setupClusterConnection，ClusterConnection提供访问cluster里所有server的方式。

5. 使用tableLockManager.reapWriteLocks将zk上所有没有释放的write lock清除掉。

6. 调用initializeZKBasedSystemTrackers()， 它完成以下工作：

   1. 创建balancer， 用于平衡regionserver管理的region数量，不至于regionserver负载不均衡, 默认使用StochasticLoadBalancer作为负载均衡器。用户可以实现接口LoadBalancer自定义均衡器，通过配置hbase.master.loadbalancer.class使其生效，balancer只负责安一定策略返回region应该放在哪个regionserver上（RegionPlan），但是具体的发送rpc给region server打开region的操作是有assignManager负责。
   2. normalizer，用于region的split和merge使得一个table的所有region的大小趋于均衡，默认使用SimpleRegionNormalizer， 用户可以实现接口RegionNormalizer自定义normalizer，通过配置hbase.master.normalizer.class引入。
   3. 创建并启动loadBalancerTracker，它监听zk的/hbase/balancer节点获知当前cluster是否容许尽心load balance。
   4. 创建并启动regionNormalizerTracker，它监听zk的/hbase/normalizer节点获知当前cluster是否容许normalize。
   5. 创建并启动splitOrMergeTracker，它监听zk的/hbase/switch节点获知当前cluster是否容许split或者merge，我怀疑只有hbase.assignment.usezk设置为false（表示merge，split不使用zk管理状态）时才起作用。否则就算你disable split也不会生效。
   6.创建assignmentManager并注册到zkListener,开始监听/hbase/region-in-transition节点,还负责命令region server打开region
   7. 创建并启动regionServerTracker，监听/hbase/rs获知hregion server的生死
   8.创建并启动drainingServerTracker， 监听/hbase/draining节点
   9. 通过clusterStatusTracker获得/hbase/running的data，由于当前hmaster成为主master，将data设置为当前hmaster的信息。只要data不为空，其他节点就会判断当前cluster是正常运行的。
   10. 创建snapshotManager
   11. 创建mpmHost，类MasterProcedureManagerHost的实例，后面会降到hmaster上的table schema创建修改都是通过Procedure实现的，mpmHost提供Procedure的运行环境。
   

7. 创建MasterCoprocessorHost， 提供hmaster上执行MasterObserver的执行环境。

8. 调用startServiceThread, 启动hmaster上的一些专门的服务线程池，主要以下类型(由ExecutorType枚举，在介绍HRegionServer时也说过region server上启动的服务):

    MASTER_CLOSE_REGION        (1),
    MASTER_OPEN_REGION         (2),
    MASTER_SERVER_OPERATIONS   (3),
    MASTER_TABLE_OPERATIONS    (4),
    MASTER_RS_SHUTDOWN         (5),
    MASTER_META_SERVER_OPERATIONS (6),
    M_LOG_REPLAY_OPS           (7),
   

9. 调用serverManager.waitForRegionServers(status);会在满足以下条件后结束等待：

   1. 向master汇报的region server数量到达配置hbase.master.wait.on.regionservers.maxtostart，不配置的话默认是Integer.MAX_VALUE.
   2. 或则同时满足： 向master汇报的region server达到hbase.master.wait.on.regionservers.mintostart配置的值，默认为1；且已经等待时间超过hbase.master.wait.on.regionservers.timeout配置值，默认4500ms，且在hbase.master.wait.on.regionservers.interval（默认1500ms）内向master注册的region server数量没有变。

   注：region server在启动时的run()方法内会不停调用reportForDuty向master汇报（通过rpc访问master的MasterRpcServices#regionServerStartup，该方法最终会走到serverManager），如果master准备好了，region server收到master正常回复，就不再调用reportForDuty。

10. 结下来是恢复meta region的过程：

1. 首先调用fileSystemManager.getFailedServersFromLogFolders()获得认为没有启动或启动失败的region server。逻辑是这样的：/hbase/WALs下每一个region server都有一个子路径，通过serverManager获得注册成功的onlineServers，从/hbase/WALs中解析出所有的server，不在onlineServer中即认为失败。
2. 通过MetaTableLocator.getMetaRegionLocation获得meta region所在的region server，原理就是从zookeeper的/hbase/meta-region-server获得之前meta region所在的server。
3. 如果2中获得的meta region所在的server在1的失败server 列表中，则认为meta region需要恢复，
4. 从3中判断出metaregion需要恢复，则调用splitMetaLogBeforeAssignment，这个方法判断recoveryMode是LOG_REPLAY还是LOG_SPLITTING，前者将meta region放到zk的/hbase/recovering-regions下,后者的meta region所在的failed region server的wal log做split log。
5. 无论4是哪一种情况，meta region最终还是要通过assignMeta将meta region给某个online的 region server管理。

1. 接下来是其他的非meta region所在的server的恢复，有如下代码调用：

   //previouslyFailedServers 是10-1中判断出来的dead server
   for (ServerName tmpServer : previouslyFailedServers) {
         this.serverManager.processDeadServer(tmpServer, true);
   }
   

   调用ServerManager#processDeadServer会将这些server保存起来，master不会等待他们都恢复完再继续(因为这一过程涉及到wal log的split以及region的assign，会比较慢)。在master启动初始化过程中，只会做meta region的恢复工作。

2. 接着是下面代码调用

   this.assignmentManager.joinCluster();
   
   

   assignmentManager，从名字上也大致能看出来是负责region到region server的assign，对于新建的region，要迁移的region，failed的region server上的region都需要assign到新的region server上。这里只记录一下joinClutser干了什么:

   1. 调用Set<ServerName> rebuildUserRegions()获得dead servers。
   这里有两个列表： replicasToClose保存需要重新assign的region，offlineServers保存dead server。
   在方法里扫描meta table(10中已经恢复了meta region)，处于merge状态的region包括其repicas region加入replicasToClose列表，状态是SPLIT的region加入replicasToClose。 region所在server不在onlineServer（10 - 1 serverManager）里的加入offlineServers，
   2. 接下来调用processDeadServersAndRegionsInTransition处理deadServer和正在merge或transition没有完成的region。在这个方法里判断需不需要这次hmaster启动需不需要做一些恢复工作（是不是failover），满足这些条件则认为需要：
       - serverManager里有deadServer；
       - zk的/hbase/region-in-transition节点不空(表示有split或者 
         merge还没有完成的region);
       - 步骤11中的deadserver的wal路径下有正在分裂的log
     总之如果不是failover则直接调用assignAllUserRegions将region赋给server。
     是failover，调用processDeadServersAndRecoverLostRegions，处理deadserver是通过ServerCrashProcedure异步完成（这个过程有deadserver的log split和region reassign）。处理in-transition的region是同步完成。
   

3. 接下来是一组scheduledChore的调度,scheduledChore有ChoreService定期调度执行。

   /*
   clusterStatusChore通过HMaster#getClusterStatus获得clusterStatus， clusterMaster包含：
      - 从zk获得的backup master
      - 从assignmentManager获得的in-transition的region
      - 从masterCoprocessorHost获得的注册到master的coprocessor
      - 从serverManager获得的dead|online server以及online server的
        ServerLoad的这些信息. 
   获得的clusterStatus被设置到loadBalancer的成员上，loadBalancer使用这些信息来决定region到server的assign。
   */ 
   this.clusterStatusChore = new ClusterStatusChore(this, balancer);
   getChoreService().scheduleChore(clusterStatusChore);
   
   /**
   BalancerChore调用Hmaster#balance, 最终是通过loadBalancer获得RegionPlan(一个plan包括需要移动的region info，源region server和目的region server)。loadBalancer只负责根据当前的clusterStatus以一定的策略生成RegionPlan，region的迁移则是由assignmentManager根据plan完成，
   */
   this.balancerChore = new BalancerChore(this);
   getChoreService().scheduleChore(balancerChore);
   
   /**
   首先normalizer的作用的将过大的region split,将太小的region merge。
   normalizerChore调用RegionNormalizer， 扫描table的region，生成Split或者Meger plan，然后通过AdminService这个rpc调用到某个region server让其对region split或者merge。
   */
   this.normalizerChore = new RegionNormalizerChore(this);
       getChoreService().scheduleChore(normalizerChore);
   
   /**
   对于已经被merge成一个region m的region a,b和对于split成两个region c，d的region p, 定期扫描meta table，如果m不在持有a，b的reference file， c，d不再持有p的reference file，那么就可以完全移除a,b 或者p。
   注：并不是真正的删除，而是将region的HFile移动到/hbase/archive/{tableName}/{encoded-region-name}路径下面
   */
   this.catalogJanitorChore = new CatalogJanitor(this, this);
       getChoreService().scheduleChore(catalogJanitorChore);
   
    periodicDoMetricsChore = new PeriodicDoMetrics(msgInterval, this);
   getChoreService().scheduleChore(periodicDoMetricsChore);
   
   

4. initNamespace()

   创建TableNamespaceManager，这是创建、访问、操作namespace这张表的帮助类。

5. initQuotaManager();

   创建MasterQuotaManager，这是创建、访问、操作quota这张表的的帮助类

差不多HMaster启动时就完成了这些工作。

最后声明一下：这个过程实在复杂，或者说hbase实在复杂。本人也是因为工作的需要接触HBase内核的一些东西，也是一名新手，写出来，可能会有人看，有错误得地方在所难免，希望发现错误的人，能够指出来，十分感谢。随着学习的深入，我自己发现的问题也会更正，但是工作繁忙有可能不够及时。