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 （歷史文章查閱非常方便）