ApsaraDB-HBase雙集群和穩定性

摘要： 在2018年1月25日的資料庫直播上由阿里雲HBteam的玄陵帶來了以「ApsaraDB-HBase雙集群和穩定性」為主題的分享，通過對雲HBase雙集群方案的必要性、常見跨集群數據複製方案、雲HBase 跨集群數據複製、雲HBase雙集群方案選擇以及雲HBase服務的穩定性進行了詳細的介紹。

原文

直播視頻：https://yq.aliyun.com/video/play/1333

PPT下載：https://yq.aliyun.com/download/2460

以下內容為精彩視頻整理：

雲HBase雙集群方案的必要性

介紹一下服務做雙集群的必要性，雙集群常見於一些在線服務，因為對於在線服務來說對服務可用性更敏感，且對數據可靠性要求更高，雙集群的災備或者說一個多活的方案為在線服務提供了更優的服務穩定性。當檢測到Master集群不可用才可以把流量切換到備份集群，這就是一個災備。同時也可以做主備的集群的流量分切等，把主備的資源都利用起來。在線集群如果由於主集群掛了或者部分時間不可用，如果有backup，那麼可以瞬間流量切到備份，提高服務可用性。離線服務可能對可用性不是這麼敏感，掛了一段時間再繼續服務，可能離線服務根本不care。

常見跨集群數據複製方案

接下來先介紹一下數據複製這一模塊，常見的解決方案以及它的原理。這一模塊它會涉及到增量複製以及全量複製，先來介紹一下增量複製常見的一些解決方案，大概歸納為下面幾個方面：

1.雙寫：現在有兩個集群Master和Slave，在業務層做雙寫的服務，把流量在主集群寫一份，備份集群寫一份，任何一條寫請求過來的話，可以保證在主集群Master上和備份集群Slave上都寫成功後，這次寫才是成功的。當發現主集群掛掉了，可以把流量倒到備份集群上；

2.複製log：在增量複製的時候要先複製log，比方一個主庫一個備庫，先把寫流量打到主庫，備庫做解析。常見的有mysqul複製binlog、mongo複製oplog、HBase複製WALlog；

3.EACH_QUORUM/LOCAL_QUORUM：同過C*cross dc back up方案；

4.Consentsus協議複製：Consentsus是做內部的數據同步；

5.其它；

全量複製大概有下面幾個方面:

（1）批量跑Map Reduce導數據（copytable）；

（2）Copy file+bulkload,從文件級別copy到備份集群，bulkload是直接從數據文件把數據load起來，最終在內存裡面以及在物理磁碟上可能會有新增的索引文件；

（3）資料庫自身方案：雲HBase有一套一鍵遷移工具和C*rebuild工具;

全面複製的特點如下：

雲HBase一鍵遷移工具可以做到表級別的複製，使用起來比較快捷，可以做到容錯和災備，還可以在線的調整它的速度。

除此之外還有一個Distcp的功能，它就是copy file+bulkload，但單機bulkload資源消耗的比較嚴重，影響在線的備份速度。

Copy table是在源端做一個scan請求，對在線的源端大量的scan是影響它的內存、以及影響它的在線請求。

雲HBase 跨集群數據增量複製

對雲HBase 做replication我們也會提供非同步複製，非同步複製和社區相比會有一些優點，下面從這幾方面介紹一下它的優點：

（1）提升源端發送效率：在複製HLog這一流程的時候，是對HLog進行的一個串列的讀取。

讓源端發送的過程進行多線程並發的操作，這樣對發送的效率有所提高，進而對接收效率也進行提高；

（2）提升目標端Sink的效率：源端預合併HLog，目標端進行並行化消費；

（3）熱點輔助：進行基於歷史監控的負載均衡演算法均衡請求，進行人工運維；

這是我們在原有非同步複製上面的一個優化，除此之外我們還做了一個基於雲HBase同步replication，因為原來的replication是非同步的，所以就HBase這個版本除此之外它還有一個同步的replication分量複製。

同步複製是發一條請求在本地先寫WALlog，同時並發在備份Cluster上寫一條RemoteLog，在本地寫memstore。同時在下面主備之間的Log複製邏輯用的是原來的非同步複製邏輯。當我現主集群掛了，把流量切到備份集群，這時備份集群自己要做一個恢復，恢復的時候就需要在RemoteLog上做一個同步的恢復。RemoteLog並不會一直存在，當發現主集群的Log非同步複製備份之後，就可以把RemoteLog刪掉了。

下面總結一下雲HBase在增量複製這一塊的優點，

（1）支持強同步複製：保證主備集群寫入強一致同步，一旦主集群掛掉了，可以在備份上讀到最全的數據;

（2）對同步和非同步做到了同存：同步複製表不影響非同步複製表的讀寫;

（3）靈活切換模式：當主集群掛了或者非同步集群掛了，同步複製可以一鍵切換為非同步複製，不阻塞主集群寫入;

（4）高性能複製：複製性能比社區是高一倍的，儘可能的並行化處理;

雲HBase雙集群方案選擇

對於在線服務會有災備的需求，也可能會有雙活的需求常見的方案有業務層做一些切換以及重試、consensus協議保證、雲HBase：DB層面做災備/雙活，業務無感知。

介紹一下之前做雙集群方案的調研。

第一種是有主備的hbase，主備集群可以共用一套Zk，在Zk裡面丟上主集群的地址和備集群的地址。當發現主集群是掛掉了，可以人工的在Zk里把地址做一個替換，請求就會直接訪問備份集群不會訪問主集群。它的優點是架構比較簡單，缺點是一旦Zk掛掉之後，主備集群就會完全無法工作。

第二種方案是主備hbase和各自的Zk，這個的好處是不會依賴於共有的Zk，Zk不會成為致命點。但在配置管理+消息推送這會有一個配置管理的工具，它專門的去存儲地址。

第三種就是我們自己的主備hbase+client retry，大部分邏輯是丟在client層面，在client上做一些判斷。還有智能的不可服務的診斷系統，當發現主機不可服務後會在網路層面把這個事做一個鎖定，Client層面感知到這個鎖定後會把流量自動的切到備份。對於put/get/delete/batch多樣化的複製，來一個put請求丟到主機里複製備份，當client層面發現主集群不可服務了，client自己會把流量切到備份。Client也有方毛刺抖動的預防功能和雲HBase非同步複製的功能。

我們之所以選擇第三種方案，因為在雲上的環境比較複雜，而方案一、二都需要依賴其他的組件，如果再在雲上加一個組件整個流程是比較複雜的，所以我們選擇了一個最簡單的方案，後期還可以在client層面做一些策略的路由，這樣可以支持後續多活的延續。

雲HBase服務穩定性

雙集群的穩定性，現在購買雙集群實現的邏輯是在同region下，不同的Az和相同的Az都是可以支持服務的，這樣可以防止區域性外界原因造成的服務不可用問題。出現單集群某些機器出現OOM問題可以把風險降到很低，不影響整體服務可用性。除此之外後續還會有一個雙活的規劃，後續支持可配策略的訪問模式，主備異構。

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎