HBase作為一個分散式儲存的資料庫，它是如何保證可用性的呢？對於分散式系統的CAP問題，它是如何權衡的呢？

最重要的是，我們在生產實踐中，又應該如何保證HBase服務的高可用呢？

下面我們來仔細分析一下。

1. 什麼是分散式系統的CAP？

CAP是指一致性（Consistency）、可用性（Availability）和分割槽容錯性（Partition tolerance）。

• Consistency 一致性

一致性指更新操作成功並返回客戶端完成後，分散式系統中所有節點在同一時間的資料完全一致。

從客戶端的角度來看，一致性主要指的是併發訪問時獲取的資料一致。從服務端來看，則是更新如何複製分佈到整個系統，以保證資料最終一致。

對於資料庫來說，如果要求更新過的資料能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的資料，則是最終一致性。

• Availability 可用性

可用性指服務一直可用，整個系統是可以正常響應的。 一般我們在衡量一個系統的可用性的時候，都是通過停機時間來計算的。我們經常說的3個9，4個9的SLA，就是對於可用性的量化表述。

• Partition Tolerance分割槽容錯性

分割槽容錯性指分散式系統在遇到某節點或網路分割槽故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

而CAP定理證明，一個分散式系統最多隻能同時滿足這三項中的兩項。

由於分散式系統中必然存在網路分割槽，所以對於分散式系統而言，一般分為CP系統和AP系統。

也就是說，如果出現故障了，到底是選擇可用性優先（AP）呢？還是選擇一致性優先(CP)？

2.HBase的CAP權衡

HBase作為分散式資料庫，同樣滿足CAP理論，那它是AP系統，還是CP系統呢？

我們從HBase的故障恢復過程來分析一下。

當某臺region server fail的時候，它管理的region failover到其他region server時，需要根據WAL log（Write-Ahead Logging）來redo，這時候進行redo的region應該是不可用的，客戶端請求對應region資料時，會丟擲異常。

因此，HBase屬於CP型架構，降低了可用性，具備強一致性讀/寫。

設想一下，如果redo過程中的region能夠響應請求，那麼可用性提高了，則必然返回不一致的資料(因為redo可能還沒完成)，那麼hbase的一致性就降低了。

3.HBase的可用性分析

作為一個CP系統，HBase的可用性到底如何，我們還需要進一步分析它的各個元件。

下面是一個HBase叢集的相關元件。

 

以HBase 單叢集 2個master + 3個core 節點作為例子，各個元件的部署情況如下：

 

 

HBase:

• 兩個HMaster互為主備，保證高可用
• 藍色的region server表示會存有meta table
• 使用者快取meta table資訊，直接與region server互動，查詢，不需要經過HMaster
• core可以橫向擴充套件，存在多個region server和data node。

Zookeeper：

• 三節點叢集

HDFS：

• 兩個namenode，多個DataNode

在這樣的部署下，各個元件的可用性分析如下：

 

從上面的分析可以看到，HBase的不可用風險主要有兩個：

1）某個region server不可用，導致該region server上的流量有分鐘級的不可讀寫

2）叢集整體不可用，所有流量不可讀寫

4. 如何提高HBase可用性

4.1 Region replica

上面提到了HBase為了保證資料的強一致性，在可用性上有所犧牲，根本原因是雖然是三副本的資料儲存，但是同一時刻只有一個“線上”Region（保證一致性），所以一旦該region不可用，需要通過日誌回放來重新拉起一個新的region，而且此時region不可讀寫（保證一致性）。

因此，如果能增加“線上”的Region數量，就可以提高可用性了，可以參考這個Region replica（https://issues.apache.org/jira/browse/HBASE-10070 ）。需要注意，副本region只能作為讀，不能作為寫。因此主region掛了以後，仍然會有不可寫入時間。

這個特性沒有很多的生產實踐案例，風險較高，因此不建議使用。

4.2 主備叢集

既然單叢集HBase的可用性不夠，我們自然而然會想到可以使用主備叢集來提高可用性。

如果一個叢集的穩定性是99.9%, 那麼兩個獨立叢集的組合的穩定性是 1 - 0.1 * 0.1 = 99.99%。採用主備叢集服務同一份資料，可以在最終一致性條件下提升一個數量級的穩定性。

我們參考下阿里雲HBase的主備叢集模式，一般有兩種模式，主備雙活與主備容災。

1）主備雙活（active-active模式）

可以實現兩方面的能力，降低毛刺與自動容錯

• 降低毛刺

當客戶端發起請求後，會首先向主叢集發起請求,在等待一段時間(Glitch Time)後如果主庫仍沒有返回結果,則併發向備庫發起請求，最終取最快返回的值作為結果。

 

 

• 自動容錯

當主叢集連續拋錯或者連續超時超過使用者指定次數時,即判定主叢集存在故障需要進行”切換”,在切換狀態下在主庫服務恢復可以進行正常訪問的情況會進行自動回切,對使用者完全透明。

 

 

優點：

• 主備雙活能大大提高HBase服務的可用性，能實現region server宕機的快速恢復和叢集整體不可用的快速恢復。

缺點：

• 犧牲一致性後換來的高可用性。既然主備叢集之間需要資料同步，那麼必然存在延遲，那麼在自動切換讀取備叢集的時候，就可能存在資料不一致的情況。而且資料不一致可能是一種低概率的常態化情況。

2）主備容災（active-standby模式）

同樣是主備叢集，但是正常情況下都是訪問主叢集。如果主叢集出現故障，那麼就可以通過手動切換的方式，快速切換到備叢集。

 

優點：

• 主備容災在故障時能快速恢復，大大降低故障恢復時間，提高可用性。能實現region server宕機的快速恢復和叢集整體不可用的快速恢復。
• 只有在切換到過程中，可能存在資料不一致的情況。

缺點：

• 無法像主備雙活那樣降低毛刺
• 手動切換，切換不夠迅速、絲滑

4.3 互備雙活

主備叢集的方案雖然大大提高了可用性，但是我們可以明顯感受到的是，成本double了。日常情況下，備用叢集一般都是閒置的。這對於生產實踐來說，是不容忽視的考慮因素。

因此，我們在主備叢集的基礎上，可以考慮“互為主備”的方案。

所謂“互為主備”，就是兩個業務有各自的HBase叢集，同時，通過資料雙向同步，在對方的叢集中備份資料，作為備叢集。

得益於HBase的儲存與計算分離的特點，我們只需要冗餘儲存，而不需要冗餘計算資源。

優點：

• 通過主備叢集的基礎架構，提高了可用性，比如一般的某個region server宕機，可以大大提高恢復速度。
• 降低了成本，不再需要完全的double成本，且有一個叢集日常空閒

缺點：

• 無法支援叢集整體不可用後的切換。由於兩個叢集都是以自身業務容量來規劃使用的，雖然日常安全使用水位是60%以下，可以支援region server宕機的流量切換，但是如果整個叢集不可用導致的整個叢集切換，那麼勢必會沖垮備用叢集（除非冗餘計算資源，那麼還是成本double了，沒有意義）。

5.總結

我們分析了HBase單叢集的可用性，然後針對HBase的CP型分散式系統，給出了通過主備叢集提高可用性的方案。並且，根據成本考慮，給出了非叢集故障下的“互備雙活”方案。

我們需要根據業務的重要程度、對於不可讀寫的容忍程度來評估具體的可用性方案，希望能對大家有所啟發。

 

看到這裡了，原創不易，點個關注、點個贊吧，你最好看了～

知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）

掃碼關注我的公眾號“阿丸筆記”，第一時間獲取最新更新。同時可以免費獲取海量Java技術棧電子書、各個大廠面試題。

相關推薦