網易視頻雲技術分享：HBase高可用原理與實踐

標籤：

網易視頻雲是網易傾力打造的一款雲端式計算的分布式多媒體處理叢集和專業音視頻技術，提供穩定流暢、低時延、高並發的ApsaraVideo for Live、錄製、儲存、轉碼及點播等音視頻的PAAS服務，線上教育、遠程醫學、娛樂秀場、線上金融等各行業及企業使用者只需經過簡單的開發即可打造線上音視頻平台。現在，網易視頻雲的技術專家給大家分享一則技術文：HBase高可用原理與實踐。

前言

前段時間有套線上HBase出了點小問題，導致該套HBase叢集服務停止了2個小時，從而造成使用該套HBase作為資料存放區的應用也出現了服務異常。在排查問題之餘，我們不禁也在思考，以後再出現類似的問題怎麼辦？這種問題該如何避免？用慣了MySQL，於是乎想到了HBase是否跟MySQL一樣，也有其高可用方案？

答案當然是肯定的，幾乎所有的資料庫(無論是關係型還是分布式的)，都採用WAL的方式來保障服務異常時候的資料恢複，HBase同樣也是通過WAL來保障資料不丟失。HBase在寫資料前會先寫HLog，HLog中記錄的是所有資料的變動， HBase的高可用也正是通過HLog來實現的。

進階

HBase是一個沒有單點故障的分布式系統，上層(HBase層)和底層(HDFS層)都通過一定的技術手段，保障了服務的可用性。上層HMaster一般都是高可用部署，而RegionServer如果出現宕機，region遷移的代價並不大，一般都在毫秒層級完成，所以對應用造成的影響也很有限；底層儲存依賴於HDFS，資料本身預設也有3副本，資料存放區上做到了多副本冗餘，而且Hadoop 2.0以後NameNode的單點故障也被消除。所以，對於這樣一個本身沒有單點故障，資料又有多副本冗餘的系統，再進行高可用的配置是否有這個必要？會不會造成資源的極大浪費？

高可用部署是否有必要，這個需要根據服務的重要性來定，這裡先簡單介紹下沒有高可用的HBase服務會出現哪些問題：

資料庫管理員失誤，進行了無法復原的DDL操作

不管是什麼資料庫，DDL操作在執行的時候都需要慎之又慎，很可能一條簡單的drop操作，會導致所有資料的丟失，並且無法恢複，對於HBase來說也是這樣，如果管理員不小心drop了一個表，該表的資料將會被丟失。

離線MR消耗過多的資源，造成線上服務受到影響

HBase經過這麼多年的發展，已經不再是只適合離線業務的資料存放區分析平台，許多公司的線上業務也相繼遷移到了HBase上，比較典型的如：facebook的Messages系統、360的搜尋業務、小米米聊的曆史資料等等。但不可避免在這些資料上做些統計分析類操作，大型MR跑起來，會有很大的資源消耗，可能會影響線上業務。

不可預計的另外一些情況

比如核心交換器故障，機房停電等等情況都會造成HBase服務中斷

對於上述的那些問題，可以通過配置HBase的高可用來解決：

無法復原DDL問題

HBase的高可用不支援DDL操作，換句話說，在master上的DDL操作，不會影響到slave上的資料，所以即使在master上進行了DDL操作，slave上的資料依然沒有變化。這個跟MySQL有很大不同，MySQL的DDL可以通過statement格式的Binlog進行複製。

離線MR影響線上業務問題

高可用的最大好處就是可以進行讀寫分離，離線MR可以直接跑在slave上，master繼續對外提供寫服務，這樣也就不會影響到線上的業務，當然HBase的高可用複製是非同步進行的，在slave上進行MR分析，資料可能會有稍微延遲。

意外情況

對於像核心交換器故障、斷電等意外情況，slave跨機架或者跨機房部署都能解決該種情況。

基於以上原因，如果是核心服務，對於可用性要求非常高，可以搭建HBase的高可用來保障服務較高的可用性，在HBase的Master出現異常時，只需簡單把流量切換到Slave上，即可完成容錯移轉，保證服務正常運行。

原理

HBase高可用保證在出現異常時，快速進行容錯移轉。下面讓我們先來看看HBase高可用的實現，首先看下官方的一張圖：

HBase Replication

需要聲明，HBase的replication是以Column Family為單位的，每個Column Family都可以設定是否進行replication。

中，一個Master對應了3個Slave，Master上每個RegionServer都有一份HLog，在開啟Replication的情況下，每個RegionServer都會開啟一個線程用於讀取該RegionServer上的HLog，並且發送到各個Slave，Zookeeper用於儲存當前已經發送的HLog的位置。Master與Slave之間採用非同步通訊的方式，保障Master上的效能不會受到Slave的影響。用Zookeeper儲存已經發送HLog的位置，主要考慮在Slave複製過程中如果出現問題後重建立立複製，可以找到上次複製的位置。

HBase Replication步驟

HBase Client向Master寫入資料

對應RegionServer寫完HLog後返回Client請求

同時replication線程輪詢HLog發現有新的資料，發送給Slave

Slave處理完資料後返回給Master

Master收到Slave的返回資訊，在Zookeeper中標記已經發送到Slave的HLog位置

註：在進行replication時，Master與Slave的配置並不一定相同，比如Master上可以有3台RegionServer，Slave上並不一定是3台，Slave上的RegionServer數量可以不一樣，資料如何分布這個HBase內部會處理。

種類

HBase通過HLog進行資料複製，那麼HBase支援哪些不同種類的複製關係？

從複製模式上來講，HBase支援主從、主主兩種複製模式，也就是經常說的Master-Slave、Master-Master複製。

Master-Slave

Master-Slave複製比較簡單，所有在Master叢集上寫入的資料都會被同步到Slave上。

Master-Master

Master-Master複製與Master-Slave類似，主要的不同在於，在Master-Master複製中，兩個Master地位相同，都可以進行讀取和寫入。

既然Master-Master兩個Master都可以進行寫入，萬一出現一種情況：兩個Master上都進行了對同一表的相同Column Family的同一個rowkey進行寫入，會出現什麼情況？

create  ‘t’,  {NAME=>’cf’, REPLICATION_SCOPE=>’1’}

Master1                                                                      Master2

put ‘t’, ‘r1’, ‘cf’, ‘aaaaaaaaaaaaaaa’                       put ‘t’, ‘r1’, ‘cf’, ‘bbbbbbbbbbbbbbb’

如上操作，Master1上對t的cf列簇寫入rowkey為r1，value為aaaaaaaaaaaaaaa的資料，Master2上同時對t的cf列簇寫入rowkey為r1, value為bbbbbbbbbbbbbbb的資料，由於是Master-Master複製，Master1和Master2上在寫入資料的同時都會把更新發送給對方，這樣最終的資料就變成了：

Master1    Master2    

rowkey    value    rowkey    value    

r1    bbbbbbbbbbbbbbb    r1    aaaaaaaaaaaaaaa    

從上述表格中可以看到，最終Master1和Master2上cf列簇rowkey為r1的資料兩邊不一致。

所以，在做Master-Master高可用時，確保兩邊寫入的表都是不同的，這樣能防止上述資料不一致問題。

異常

HBase複製時，都是通過RegionServer開啟複製線程進行HLog的發送，那麼當其中某個RegionServer出現異常時，HBase是如何處理的？這裡需要區別兩種不同的情況，即Master上RegionServer異常和Slave上RegionServer異常。

Slave上RegionServer異常

對於該種異常HBase處理比較簡單，Slave上出現某個RegionServer異常，該RegionServer直接會被標記為異常狀態，後續所有的更新都不會被發送到該台RegionServer，Slave會重新選取一台RegionServer來接收這部分資料。

Master上RegionServer異常

Master上RegionServer出現異常，由於HLog都是通過RegionServer開啟複製線程進行發送，如果RegionServer出現異常，這個時候，屬於該台RegionServer的HLog就沒有相關處理線程，這個時候，這部分資料又該如何處理？

Master上某台RegionServer異常，其他RegionServer會對該台RegionServer在zookeeper中的資訊嘗試加鎖操作，當然這個操作是互斥的，同一時間只有一台RegionServer能擷取到鎖，然後，會把HLog資訊拷貝到自己的目錄下，這樣就完成了異常RegionServer的HLog資訊的轉移，通過新的RegionServer把HLog的資訊發送到Slave。

Master regionserver crash

操作

上面介紹的都是HBase高可用的理論實現和異常處理等問題，下面就動手實踐下，如何配置一個HBase的Replication(假設已經部署好了兩套HBase系統，並且在設定檔中已經開啟了replication配置)，首先嘗試配置下Master-Slave模式的高可用：

選取一套系統作為Master，另外一套作為Slave

在Master上通過add_peer 命令添加複製關係，如下

add_peer ‘1’, “db-xxx.photo.163.org:2181:/hbase”

在Master上建立表t，該表擁有一個列簇名為cf，並且該列簇開啟replication，如下：

create ‘t’, {NAME=>’cf’, REPLICATION_SCOPE=>’1’}

上面REPLICATION_SCOPE的值需要跟步驟2中的對應

在slave建立相同的表(HBase不支援DDL的複製)，在master-slave模式中，slave不需要開啟複製，如下：

create ‘t’, {NAME=>’cf’ }

這樣，我們就完成了整個master-slave模式高可用的搭建，後續可以在master上通過put操作插入一條記錄，查看slave上是否會複製該記錄，最終結果如下：

Master上操作

Slave上結果

上述結果顯示，在添加完複製關係後，Master上插入rowkey=r1, value=’aaaaaaaaa’的記錄，slave上可以擷取該記錄，Master-Slave模式資料複製成功。

接下來我們再看下Master-Master模式的複製，配置的時候與Master-Slave模式不同的是，在Master上添加完複製關係後，需要在另外一台Master也添加複製關係，而且兩邊的cluster_id必須相同，並且在另外一台Master上建表的時候，需要加上列簇的REPLICATION_SCOPE=>’1’配置，最終結果如下：

Master1上操作

Master2上操作

上述結果顯示，添加完了Master-Master複製關係，在Master1上插入一條記錄rowkey=r1, value=“aaaaaaaaaa”，Master2上通過scan操作發現該記錄已經被複製到Master2上，接著我們在Master2上添加一條記錄rowkey=r2, value=’bbbbbbbbbbbb’，查看Master1上的資料，該條記錄也已經被複製到Master2上，Master-Master模式的replication驗證成功。

網易視頻雲技術分享：HBase高可用原理與實踐