本文基于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管理。

11. 接下來是其他的非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的恢復工作。

12. 接著是下面代碼調用

    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是同步完成。
    

13. 接下來是一組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);
    
    

14. initNamespace()

    創建TableNamespaceManager，這是創建、訪問、操作namespace這張表的幫助類。

15. initQuotaManager();

    創建MasterQuotaManager，這是創建、訪問、操作quota這張表的的幫助類

差不多HMaster啟動時就完成了這些工作。

最后聲明一下：這個過程實在復雜，或者說hbase實在復雜。本人也是因為工作的需要接觸HBase內核的一些東西，也是一名新手，寫出來，可能會有人看，有錯誤得地方在所難免，希望發現錯誤的人，能夠指出來，十分感謝。隨著學習的深入，我自己發現的問題也會更正，但是工作繁忙有可能不夠及時。