摘  要： 主要介紹了HBase RegionServer與Zookeeper間的交互過程，闡述RegionServer崩潰后的恢復機制，并在此基礎上提出了幾點優化的恢復措施。優化后的恢復措施大大縮短了RegionServer崩潰后的故障恢復時間和業務中斷時間，從而提高了HBase集群的穩定性和可靠性。

　　關鍵詞： HBase；RegionServer；崩潰；恢復

0 引言

　　隨著互聯網和通信行業的迅猛發展，積聚的各種數據呈急劇增長態勢。這些海量數據既蘊含著豐富的信息和資源，又面臨著信息有效管理和提取的難題。云計算是分布式處理、并行處理和網格計算的發展，可以提供近乎無限的廉價存儲和計算能力，特別適合于日益暴增的海量數據的存儲和處理。在云計算領域中，Hadoop體系獨樹一幟，其豐富的子系統可以滿足多種領域和行業的應用需求，而其中的HBase作為一種非結構化數據庫，特別適合于各種非結構化和半結構化的松散數據的存儲和管理。

　　HBase是一個高可靠性、高性能、面向列、可伸縮、實時讀寫的分布式存儲數據庫系統[1-3]。HBase建立在HDFS分布式文件系統基礎之上，其中的數據最終以HFile的格式存儲在HDFS之上；HBase可以通過內嵌的MapReduce組件實現復雜任務的并行和分布處理，具有很高的性能。

　　1 HBase體系結構

　　HBase主要由HMaster和RegionServer兩部分組成，輔以Zookeeper協調集群中各網元之間的數據共享和訪問，其組成框圖如圖1所示[4]。

　　（1）Client：訪問HBase的接口，維護著一些加快HBase訪問的緩存，比如Region的位置信息等。

　　（2）Master：負責Region到RegionServer的分配以及映射關系維護；管理集群中的RegionServer及其負載均衡；維護數據表和其所在Region的元數據信息；處理表級的操作請求等。

　?。?）RegionServer：維護Master分配給它的Region，處理對這些Region的讀寫請求；負責運行過程中過大的Region的Split和Compact操作。

　　（4）Zookeeper：保證任何時候集群中只有一個激活的Master；存儲RootRegion和Master的位置；存儲所有RegionServer的位置并實時監控其狀態；存儲HBase的其他運行所需的信息[5]。

　　HBase中的數據單元通過主鍵、列簇、列名和版本號唯一確定，所有行按字典順序排列。HBase中的表在行的方向上分割為多個Region，每個Region只存儲表中某一范圍的數據，并且每個Region只能被一個RegionServer管理。Region由一個或者多個Store組成，每個Store保存一個列簇；Store又由一個MemStore和0至多個storefile組成，storefile以HFile的格式存儲于HDFS上。

　　由此可見，HBase中的表通常被劃分為多個Region，而各個Region可能被不同的RegionServer所管理。客戶端通過Master和相關操作獲取目標Region的位置后，最終通過RegionServer完成對用戶表的讀寫請求。因此，如果某個RegionServer異常，客戶端對其所管理的Region的訪問就會失敗，造成了業務中斷，這在在線系統中是不可接受的。雖然HBase中實現了RegionServer異常后的自動恢復機制，但是這種機制的時延很大，不能滿足實際應用需求。因此，本文針對這部分進行了研究，并提出了一種可以快速、高效恢復業務的方法。

2 HBase集群與Zookeeper交互機制分析

　　在HBase的使用過程中，Zookeeper起著至關重要的作用。正是Zookeeper的存在，使得HBase的運行更加穩定和高效。

　　在配置環境中，Zookeeper集群中的HBase的目錄如圖2所示。

　　HBase集群的相關信息存儲在Zookeeper集群中的hbase目錄（這個目錄是可以配置的）下，其中master目錄存儲HMaster的位置等相關信息，rs目錄存儲所有的RegionServer的位置等相關信息。

　　在HMaster啟動時，會在Zookeeper集群中創建自己的ZNode臨時節點并獲得該節點的獨占鎖，該節點位于Zookeeper集群中的/hbase/master目錄下。同時會在所有的其他目錄上創建監聽，這樣當其他節點的狀態發生變化時，HMaster就可以立即感知從而進行相應的處理。

　　在RegionServer啟動時，會在Zookeeper集群中創建自己的ZNode臨時節點并獲得該節點的獨占鎖，這個節點位于Zookeeper集群中的/hbase/rs目錄下。

　　RegionServer會通過Socket連接向Zookeeper集群發起Session會話，會話建立后在Zookeeper集群中創建屬于自己的臨時節點ZNode。這個節點的狀態是由Zookeeper集群依據Session的狀態來維護的。

　　RegionServer作為客戶端，向Zookeeper集群的Server端發起Session會話請求。Session建立后，會以唯一的SessionID作為標示。Client會定期向Server端發送Ping消息來表達該Session的存活狀態；而Server端收到Ping消息時會更新當前Session的超時時間。如此，對于Client而言，只要Ping信息可達則表明該Session激活；對于Server而言，只要Session未超時則表明該Session激活。

　　在Server端，Zookeeper會啟動專門的SessionTrackerImpl線程來處理Session的相關狀態遷移問題，該線程每隔tickTime（Zookeeper配置文件中指定，默認為2 s）時間遍歷一次Session列表，如果超時則立即關閉此Session，同時刪除與該Session關聯的臨時節點，并將該事件通知給注冊了該節點事件的組件。在HBase集群中，這就意味著如果RegionServer崩潰，則Zookeeper需要在Session超時后才能通知Master，后者才能啟動故障恢復。

　　而Session的超時時間是這樣確定的：HBase默認的Timeout為180 s，在創建Session時會將該參數傳遞給Server端。最終協商確定的Session的超時時間由Zookeeper的配置參數決定，處于Zookeeper集群minSessionTimeout和maxSessionTimeout之間。默認的minSessionTimeout=2×tickTime（默認2 s）=4 s，maxSessionTimeout=20×tickTime=40 s。不管Client傳遞的Timeout多大，最終協商確定的Session的Timeout時間都在4~40 s之間，實現代碼如下。如果一切按照默認配置，則Session的Timeout為40 s。

　　int sessionTimeout=connReq.getTimeOut（）；

　　int minSessionTimeout=getMinSessionTimeout（）；

　　if（sessionTimeout<minSessionTimeout）{

　　sessionTimeout=minSessionTimeout；

　　}

　　int maxSessionTimeout=getMaxSessionTimeout（）；

　　if（sessionTimeout>maxSessionTimeout）{

　　sessionTimeout=maxSessionTimeout；

　　}

　　cnxn.setSessionTimeout（sessionTimeout）；

　　經以上分析，可以得出以下結論：Session存活意味著RegionServer存活；Session超時意味著RegionServer啟動時創建的ZNode節點被刪除，也就表明該RegionServer異常。

3 HBase中RegionServer異常后的恢復機制分析

　　通過以上的分析可以看出，當HBase集群中的一個RegionServer崩潰（如RegionServer進程掛掉）后，此時該RegionServer和Zookeeper集群的Server間的Socket連接會斷開，但是二者之間的Session由于有超時時間的存在而不會立即被刪除，需要等到Session超時之后才會被Zookeeper集群刪除，只有Session超時了Zookeeper集群才會刪除該RegionServer啟動時創建的臨時節點。只有Zookeeper集群中代表此RegionServer的節點刪除后，HMaster才可以得知該RegionServer發生故障，才能啟動故障恢復流程。HMaster恢復故障時，將故障RegionServer所管理的Region一個一個重新分配到集群中。

　　由此可得出以下結論：Session Timeout的存在使得HMaster無法立即發現故障RegionServer，從而延遲了故障的恢復時間，間接增加了業務中斷的時間。同時，HMaster重新分配Region的處理過程效率太低，尤其是Region數目很大時。

4 改進的RegionServer異常后的恢復措施

　　針對以上場景，本文進行了如下改進：

　　（1）在RegionServer的啟動腳本中加入特殊處理的代碼，在該RegionServer的進程結束前自動刪除其在Zookeeper集群中創建的ZNode節點，這樣HMaster就能立即感知到RegionServer的狀態異常事件，盡早地啟動異?；謴?，代碼如下。

　　cleanZNode（）

　　{

　　if[-f $HBASE_ZNODE_FILE]；then

　　#call ZK to delete the node

　　ZNODE=`cat $HBASE_ZNODE_FILE`

　　$bin/hbase zkcli delete $ZNODE>/dev/null 2>&1

　　rm $HBASE_ZNODE_FILE

　　fi

　　}

　?。?）在HMaster的恢復過程中加入特殊處理的代碼，通過批量處理，將故障RegionServer所管理的Region一次性地分配到集群中，如同HBase集群啟動時批量分配Region的過程，提高Region分配的速度。所謂批量分配，就是先獲取故障RegionServer所管理的Region數目rn和存活的RegionServer的數目rs，按照平均負載的原則，在每個存活的RegionServer上分配rn/rs個Region。這樣就可以將多個Region一次分配給一個RegionServer；而原來的分配過程則是一次分配一個Region到一個RegionServer上，顯然改進后的處理效率更高，尤其是Region數目較多時尤為明顯。

　　采用以上的處理方式后，HBase集群中當一個或幾個RegionServer發生故障后，業務的恢復速度提升了幾十倍，從最初的故障恢復時間40 s左右到現在的幾秒，實測數據如表1所示。

5 結論

　　本文在論述HBase集群與Zookeeper集群的交互機制以及RegionServer發生故障后的異常處理恢復機制的基礎上，提出了提高恢復效率、降低業務中斷時間的改進方案。該方案對于RegionServer進程的異常終止和崩潰有很好的處理效果，但是對于RegionServer斷電等物理事件導致的異常則無效，這種情況只能依靠Session Timeout后的處理流程。批量恢復的處理對所有的恢復過程都是有效的，雖然其提供的改進空間較小?？傮w說來，本文提出的RegionServer崩潰后的改進措施在通常情況下能夠較好地改進現有HBase集群的性能，縮短故障恢復時間，提高故障恢復效率，從而能有效縮短業務中斷時間。

　　參考文獻

　　[1] Apache. HBase-0.96.2 release notes[EB/OL]. [2013-07-21].http：//qnalist.com/q/hbase-user.

　　[2] Cloudera. HBase-0.94.2-cdh4.2.0 reference guidep[EB/OL].[2013-07-28].http：//newitfarmer.com/category/big_data/cloudera-big_data.

　　[3] 陸嘉恒. Hadoop實戰（第二版）[M]. 北京：機械工業出版社，2012.

　　[4] GEORGE L. HBase： the definitive guide[M]. Sebastopol： O′Reilly Media， 2011.

　　[5] Apache. ZooKeeper-3.4.5 release notes[EB/OL]. [2012-11-19].http：//zookeeper.apache.org/doc/r.3.4.5.