來源 |?阿丸筆記

責編 | Carol

頭圖 | CSDN 下載自視覺中國

HBase作為一個分布式存儲的數據庫，它是如何保證可用性的呢？對于分布式系統的CAP問題，它是如何權衡的呢？

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

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

什么是分布式系統的CAP？

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

• Consistency 一致性

一致性指更新操作成功并返回客戶端完成后，分布式系統中所有節點在同一時間的數據完全一致。

從客戶端的角度來看，一致性主要指的是并發訪問時獲取的數據一致。從服務端來看，則是更新如何復制分布到整個系統，以保證數據最終一致。

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

• Availability 可用性

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

• Partition Tolerance分區容錯性

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

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

由于分布式系統中必然存在網絡分區，所以對于分布式系統而言，一般分為CP系統和AP系統。

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

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的一致性就降低了。

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）集群整體不可用，所有流量不可讀寫

如何提高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了，沒有意義）。

總結

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

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

推薦閱讀

• 一文帶你認識keepalived，再帶你通關LVS+Keepalived！

• 那個分分鐘處理 10 億節點圖計算的 Plato，現在怎么樣了？
  

• “谷歌殺手”發明者，科學天才 Wolfram

• 數據庫激蕩 40 年，深入解析 PostgreSQL、NewSQL 演進歷程

• 超詳細！一文告訴你 SparkStreaming 如何整合 Kafka ！附代碼可實踐

• 5分鐘！就能學會以太坊 JSON API 基礎知識！

  真香，朕在看了！

總結

以上是生活随笔為你收集整理的如何保证 HBase 服务的高可用？看看这份 HBase 可用性分析与高可用实践吧！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。