來源 |?阿丸筆記

責(zé)編 | Carol

頭圖 | CSDN 下載自視覺中國

HBase作為一個分布式存儲的數(shù)據(jù)庫，它是如何保證可用性的呢？對于分布式系統(tǒng)的CAP問題，它是如何權(quán)衡的呢？

最重要的是，我們在生產(chǎn)實踐中，又應(yīng)該如何保證HBase服務(wù)的高可用呢？

下面我們來仔細(xì)分析一下。

什么是分布式系統(tǒng)的CAP？

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

• Consistency 一致性

一致性指更新操作成功并返回客戶端完成后，分布式系統(tǒng)中所有節(jié)點在同一時間的數(shù)據(jù)完全一致。

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

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

• Availability 可用性

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

• Partition Tolerance分區(qū)容錯性

分區(qū)容錯性指分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障的時候，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

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

由于分布式系統(tǒng)中必然存在網(wǎng)絡(luò)分區(qū)，所以對于分布式系統(tǒng)而言，一般分為CP系統(tǒng)和AP系統(tǒng)。

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

HBase的CAP權(quán)衡

HBase作為分布式數(shù)據(jù)庫，同樣滿足CAP理論，那它是AP系統(tǒng)，還是CP系統(tǒng)呢？

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

當(dāng)某臺region server fail的時候，它管理的region failover到其他region server時，需要根據(jù)WAL log（Write-Ahead Logging）來redo，這時候進行redo的region應(yīng)該是不可用的，客戶端請求對應(yīng)region數(shù)據(jù)時，會拋出異常。

因此，HBase屬于CP型架構(gòu)，降低了可用性，具備強一致性讀/寫。

設(shè)想一下，如果redo過程中的region能夠響應(yīng)請求，那么可用性提高了，則必然返回不一致的數(shù)據(jù)(因為redo可能還沒完成)，那么hbase的一致性就降低了。

HBase的可用性分析

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

下面是一個HBase集群的相關(guān)組件。

以HBase 單集群 2個master + 3個core 節(jié)點作為例子，各個組件的部署情況如下：

HBase:

• 兩個HMaster互為主備，保證高可用

• 藍(lán)色的region server表示會存有meta table

• 用戶緩存meta table信息，直接與region server交互，查詢，不需要經(jīng)過HMaster

• core可以橫向擴展，存在多個region server和data node。

Zookeeper：

• 三節(jié)點集群

HDFS：

• 兩個namenode，多個DataNode

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

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

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

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

如何提高HBase可用性

4.1 Region replica

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

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

這個特性沒有很多的生產(chǎn)實踐案例，風(fēng)險較高，因此不建議使用。

4.2 主備集群

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

如果一個集群的穩(wěn)定性是99.9%, 那么兩個獨立集群的組合的穩(wěn)定性是 1 - 0.1 * 0.1 = 99.99%。采用主備集群服務(wù)同一份數(shù)據(jù)，可以在最終一致性條件下提升一個數(shù)量級的穩(wěn)定性。

我們參考下阿里云HBase的主備集群模式，一般有兩種模式，主備雙活與主備容災(zāi)。

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

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

• 降低毛刺

當(dāng)客戶端發(fā)起請求后，會首先向主集群發(fā)起請求,在等待一段時間(Glitch Time)后如果主庫仍沒有返回結(jié)果,則并發(fā)向備庫發(fā)起請求，最終取最快返回的值作為結(jié)果。

• 自動容錯

當(dāng)主集群連續(xù)拋錯或者連續(xù)超時超過用戶指定次數(shù)時,即判定主集群存在故障需要進行”切換”,在切換狀態(tài)下在主庫服務(wù)恢復(fù)可以進行正常訪問的情況會進行自動回切,對用戶完全透明。

優(yōu)點：

• 主備雙活能大大提高HBase服務(wù)的可用性，能實現(xiàn)region server宕機的快速恢復(fù)和集群整體不可用的快速恢復(fù)。

缺點：

• 犧牲一致性后換來的高可用性。既然主備集群之間需要數(shù)據(jù)同步，那么必然存在延遲，那么在自動切換讀取備集群的時候，就可能存在數(shù)據(jù)不一致的情況。而且數(shù)據(jù)不一致可能是一種低概率的常態(tài)化情況。

2）主備容災(zāi)（active-standby模式）

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

優(yōu)點：

• 主備容災(zāi)在故障時能快速恢復(fù)，大大降低故障恢復(fù)時間，提高可用性。能實現(xiàn)region server宕機的快速恢復(fù)和集群整體不可用的快速恢復(fù)。

• 只有在切換到過程中，可能存在數(shù)據(jù)不一致的情況。

缺點：

• 無法像主備雙活那樣降低毛刺

• 手動切換，切換不夠迅速、絲滑

4.3 互備雙活

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

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

所謂“互為主備”，就是兩個業(yè)務(wù)有各自的HBase集群，同時，通過數(shù)據(jù)雙向同步，在對方的集群中備份數(shù)據(jù)，作為備集群。

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

優(yōu)點：

• 通過主備集群的基礎(chǔ)架構(gòu)，提高了可用性，比如一般的某個region server宕機，可以大大提高恢復(fù)速度。

• 降低了成本，不再需要完全的double成本，且有一個集群日常空閑

缺點：

• 無法支持集群整體不可用后的切換。由于兩個集群都是以自身業(yè)務(wù)容量來規(guī)劃使用的，雖然日常安全使用水位是60%以下，可以支持region server宕機的流量切換，但是如果整個集群不可用導(dǎo)致的整個集群切換，那么勢必會沖垮備用集群（除非冗余計算資源，那么還是成本double了，沒有意義）。

總結(jié)

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

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

推薦閱讀

• 一文帶你認(rèn)識keepalived，再帶你通關(guān)LVS+Keepalived！

• 那個分分鐘處理 10 億節(jié)點圖計算的 Plato，現(xiàn)在怎么樣了？
  

• “谷歌殺手”發(fā)明者，科學(xué)天才 Wolfram

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

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

• 5分鐘！就能學(xué)會以太坊 JSON API 基礎(chǔ)知識！

  真香，朕在看了！

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。