2017年開始阿里HBase走向公有云，我們有計劃的在逐步將阿里內部的高可用技術提供給外部客戶，目前已經上線了同城主備，將作為我們后續高可用能力發展的一個基礎平臺。本文分四個部分回顧阿里HBase在高可用方面的發展：大集群、MTTF&MTTR、容災、極致體驗，希望能給大家帶來一些共鳴和思考。

大集群

一個業務一個集群在初期很簡便，但隨著業務增多會加重運維負擔，更重要的是無法有效利用資源。首先每一個集群都要有Zookeeper、Master、NameNode這三種角色，固定的消耗3臺機器。其次有些業務重計算輕存儲，有些業務重存儲輕計算，分離模式無法削峰填谷。因此從2013年開始阿里HBase就走向了大集群模式，單集群節點規模達到700+。

隔離性是大集群的關鍵難題。保障A業務異常流量不會沖擊到B業務，是非常重要的能力，否則用戶可能拒絕大集群模式。阿里HBase引入了分組概念“group”，其核心思想為：共享存儲、隔離計算

如上圖所示，一個集群內部被劃分成多個分組，一個分組至少包含一臺服務器，一個服務器同一時間只能屬于一個分組，但是允許服務器在分組之間進行轉移，也就是分組本身是可以擴容和縮容的。一張表只能部署在一個分組上，可以轉移表到其它的分組。可以看到，表T1讀寫經過的RegionServer和表T2讀寫經過的RegionServer是完全隔離的，因此在CPU、內存上都物理隔離，但是下層使用的HDFS文件系統是共享的，因此多個業務可以共享一個大的存儲池子，充分提升存儲利用率。開源社區在HBase2.0版本上引入了RegionServerGroup。

壞盤對共享存儲的沖擊：由于HDFS機制上的特點，每一個Block的寫入會隨機選擇3個節點作為Pipeline，如果某一臺機器出現了壞盤，那么這個壞盤可能出現在多個Pipeline中，造成單點故障全局抖動。現實場景中就是一塊盤壞，同一時間影響到幾十個客戶給你發信息打電話！特別如果慢盤、壞盤不及時處理，最終可能導致寫入阻塞。阿里HBase目前規模在1萬+臺機器，每周大概有22次磁盤損壞問題。我們在解決這個問題上做了兩件事，第一是縮短影響時間，對慢盤、壞盤進行監控報警，提供自動化處理平臺。第二是在軟件上規避單點壞盤對系統的影響，在寫HDFS的時候并發的寫三個副本，只要兩個副本成功就算成功，如果第三個副本超時則將其放棄。另外如果系統發現寫WAL異常（副本數少于3）會自動滾動產生一個新的日志文件（重新選擇pipeline，大概率規避壞點）。最后HDFS自身在高版本也具備識別壞盤和自動剔除的能力。

客戶端連接對Zookeeper的沖擊：客戶端訪問hbase會和Zookeeper建立長連接，HBase自身的RegionServer也會和Zookeeper建立長連接。大集群意味著大量業務，大量客戶端的鏈接，在異常情況下客戶端的鏈接過多會影響RegionServer與Zookeeper的心跳，導致宕機。我們在這里的應對首先是對單個IP的鏈接數進行了限制，其次提供了一種分離客戶端與服務端鏈接的方案 HBASE-20159

MTTF&MTTR

穩定性是生命線，隨著阿里業務的發展，HBase逐步擴大在線場景的支持，對穩定性的要求是一年更比一年高。衡量系統可靠性的常用指標是MTTF（平均失效時間）和MTTR（平均恢復時間）

MTTF（mean time to failure）

造成系統失效的來源有：
硬件失效，比如壞盤、網卡損壞、機器宕機等
自身缺陷，一般指程序自身的bug或者性能瓶頸
運維故障，由于不合理的操作導致的故障
服務過載，突發熱點、超大的對象、過濾大量數據的請求
依賴失效，依賴的HDFS、Zookeeper組件出現不可用導致HBase進程退出

下面我介紹一下阿里云HBase在穩定性上遇到的幾個代表性問題：（注：慢盤、壞盤的問題已經在大集群一節中涉及，這里不再重復）

• 周期性的FGC導致進程退出

在支持菜鳥物流詳情業務的時候，我們發現機器大概每隔兩個月就會abort一次，因為內存碎片化問題導致Promotion Fail，進而引發FGC。由于我們使用的內存規格比較大，所以一次FGC的停頓時間超過了與Zookeeper的心跳，導致ZK session expired，HBase進程自殺。我們定位問題是由于BlockCache引起的，由于編碼壓縮的存在，內存中的block大小是不一致的，緩存的換入換出行為會逐步的切割內存為非常小的碎片。我們開發了BucketCache，很好的解決了內存碎片化的問題，然后進一步發展了SharedBucketCache，使得從BlockCache里面反序列化出來的對象可以被共享復用，減少運行時對象的創建，從而徹底的解決了FGC的問題。

• 寫入HDFS失敗導致進程退出

HBase依賴倆大外部組件，Zookeeper和HDFS。Zookeeper從架構設計上就是高可用的，HDFS也支持HA的部署模式。當我們假設一個組件是可靠的，然后基于這個假設去寫代碼，就會產生隱患。因為這個“可靠的”組件會失效，HBase在處理這種異常時非常暴力，立即執行自殺（因為發生了不可能的事情），寄希望于通過Failover來轉移恢復。有時HDFS可能只是暫時的不可用，比如部分Block沒有上報而進入保護模式，短暫的網絡抖動等，如果HBase因此大面積重啟，會把本來10分鐘的影響擴大到小時級別。我們在這個問題上的方案是優化異常處理，對于可以規避的問題直接處理掉，對于無法規避的異常進行重試&等待。

• 并發大查詢導致機器停擺

HBase的大查詢，通常指那些帶有Filter的Scan，在RegionServer端讀取和過濾大量的數據塊。如果讀取的數據經常不在緩存，則很容易造成IO過載；如果讀取的數據大多在緩存中，則很容易因為解壓、序列化等操作造成CPU過載；總之當有幾十個這樣的大請求并發的在服務器端執行時，服務器load會迅速飆升，系統響應變慢甚至表現的像卡住了。這里我們研發了大請求的監控和限制，當一個請求消耗資源超過一定閾值就會被標記為大請求，日志會記錄。一個服務器允許的并發大請求存在上限，如果超過這個上限，后來的大請求就會被限速。如果一個請求在服務器上運行了很久都沒有結束，但客戶端已經判斷超時，那么系統會主動中斷掉這個大請求。該功能的上線解決了支付寶賬單系統因為熱點查詢而導致的性能抖動問題。

• 大分區Split緩慢

在線上我們偶爾會遇到某個分區的數量在幾十GB到幾個TB，一般都是由于分區不合理，然后又在短時間內灌入了大量的數據。這種分區不但數據量大，還經常文件數量超級多，當有讀落在這個分區時，一定會是一個大請求，如果不及時分裂成更小的分區就會造成嚴重影響。這個分裂的過程非常慢，HBase只能從1個分區分裂為2個分區，并且要等待執行一輪Compaction才能進行下一輪分裂。假設分區大小1TB，那么分裂成小于10GB的128個分區需要分裂7輪，每一輪要執行一次Compaction（讀取1TB數據，寫出1TB數據），而且一個分區的Compaction只能由一臺機器執行，所以第一輪最多只有2臺機器參與，第二輪4臺，第三輪8臺。。。，并且實際中需要人為干預balance。整個過程做下來超過10小時，這還是假設沒有新數據寫入，系統負載正常。面對這個問題我們設計了“級聯分裂”，可以不執行Compaction就進入下一次分裂，先快速的把分區拆分完成，然后一把執行Compaction。

前面講的都是點，關于如何解決某個頑疾。導致系統失效的情況是多種多樣的，特別一次故障中可能交叉著多個問題，排查起來異常困難。現代醫學指出醫院應當更多投入預防而不是治療，加強體檢，鼓勵早就醫。早一步也許就是個感冒，晚一步也許就變成了癌癥。這也適用于分布式系統，因為系統的復雜性和自愈能力，一些小的問題不會立即造成不可用，比如內存泄漏、Compaction積壓、隊列積壓等，但終將在某一刻引發雪崩。應對這種問題，我們提出了“健康診斷”系統，用來預警那些暫時還沒有使系統失效，但明顯超過正常閾值的指標。“健康診斷”系統幫助我們攔截了大量的異常case，也在不停的演進其診斷智能。

MTTR（mean time to repair）

百密終有一疏，系統總是會失效，特別的像宕機這種Case是低概率但一定會發生的事件。我們要做的是去容忍，降低影響面，加速恢復時間。HBase是一個可自愈的系統，單個節點宕機觸發Failover，由存活的其它節點來接管分區服務，在分區對外服務之前，必須首先通過回放日志來保證數據讀寫一致性。整個過程主要包括Split Log、Assign Region、Replay Log三個步驟。hbase的計算節點是0冗余，所以一個節點宕機，其內存中的狀態必須全部回放，這個內存一般可以認為在10GB~20GB左右。我們假設整個集群的數據回放能力是 R GB/s，單個節點宕機需要恢復 M GB的數據，那么宕機N個節點就需要 M * N / R 秒，這里表達的一個信息是：如果R不足夠大，那么宕機越多，恢復時間越不可控，那么影響R的因素就至關重要，在Split Log、Assign Region、Replay Log三個過程中，通常Split Log、Assign Region的擴展性存在問題，核心在于其依賴單點。Split Log是把WAL文件按分區拆分成小的文件，這個過程中需要創建大量的新文件，這個工作只能由一臺NameNode來完成，并且其效率也并不高。Assign Region是由HBase Master來管理，同樣是一個單點。阿里HBase在Failover方面的核心優化是采用了全新的MTTR2架構，取消了Split Log這一步驟，在Assign Region上也做了優先Meta分區、Bulk Assign、超時優化等多項優化措施，相比社區的Failover效率提升200%以上

從客戶角度看故障，是2分鐘的流量跌零可怕還是10分鐘的流量下降5%可怕？我想可能是前者。由于客戶端的線程池資源有限，HBase的單機宕機恢復過程可能造成業務側的流量大跌，因為線程都阻塞在訪問異常機器上了，2%的機器不可用造成業務流量下跌90%是很難接受的。我們在客戶端開發了一種Fast Fail的機制，可以主動發現異常服務器，并快速拒絕發往這個服務器的請求，從而釋放線程資源，不影響其它分區服務器的訪問。項目名稱叫做DeadServerDetective

容災

容災是重大事故下的求生機制，比如地震、海嘯等自然災害造成毀滅性打擊，比如軟件變更等造成完全不可控的恢復時間，比如斷網造成服務癱瘓、恢復時間未知。從現實經驗來看，自然災害在一個人的一生中都難遇到，斷網一般是一個年級別的事件，而軟件變更引發的問題可能是月級別的。軟件變更是對運維能力、內核能力、測試能力等全方位的考驗，變更過程的操作可能出錯，變更的新版本可能存在未知Bug。另一個方面為了不斷滿足業務的需求又需要加速內核迭代，產生更多的變更。

容災的本質是基于隔離的冗余，要求在資源層面物理隔離、軟件層面版本隔離、運維層面操作隔離等，冗余的服務之間保持最小的關聯性，在災難發生時至少有一個副本存活。阿里HBase在幾年前開始推進同城主備、異地多活，目前99%的集群至少有一個備集群，主備集群是HBase可以支持在線業務的一個強保障。主備模式下的兩個核心問題是數據復制和流量切換

數據復制

選擇什么樣的復制方式，是同步復制還是異步復制，是否要保序？主要取決于業務對系統的需求，有些要求強一致，有些要求session一致，有些可以接受最終一致。占在HBase的角度上，我們服務的大量業務在災難場景下是可以接受最終一致性的（我們也研發了同步復制機制，但只有極少的場景），因此本文主要專注在異步復制的討論上。很長一段時間我們采用社區的異步復制機制（HBase Replication），這是HBase內置的同步機制。

同步延遲的根因定位是第一個難題，因為同步鏈路涉及發送方、通道、接受方3個部分，排查起來有難度。我們增強了同步相關的監控和報警。

熱點容易引發同步延遲是第二個難題。HBase Replication采用推的方式進行復制，讀取WAL日志然后進行轉發，發送線程和HBase寫入引擎是在同一臺RegionServer的同一個進程里。當某臺RegionServer寫入熱點時，就需要更多的發送能力，但寫入熱點本身就擠占了更多的系統資源，寫入和同步資源爭搶。阿里HBase做了兩個方面的優化，第一提高同步性能，減少單位MB同步的資源消耗；第二研發了遠程消耗器，使其它空閑的機器可以協助熱點機器同步日志。

資源需求、迭代方式的不匹配是第三個難題。數據復制本身是不需要磁盤IO的，只消耗帶寬和CPU，而HBase對磁盤IO有重要依賴；數據復制的worker本質上是無狀態的，重啟不是問題，可以斷點續傳，而HBase是有狀態的，必須先轉移分區再重啟，否則會觸發Failover。一個輕量級的同步組件和重量級的存儲引擎強耦合在一起，同步組件的每一次迭代升級必須同時重啟HBase。一個重啟就可以解決的同步問題，因為同時要重啟hbase而影響線上讀寫。一個擴容CPU或者總帶寬的問題被放大到要擴容hbase整體。

綜上所述，阿里HBase最終將同步組件剝離了出來作為一個獨立的服務來建設，解決了熱點和耦合的問題，在云上這一服務叫做BDS Replication。隨著異地多活的發展，集群之間的數據同步關系開始變得復雜，為此我們開發了一個關于拓撲關系和鏈路同步延遲的監控，并且在類環形的拓撲關系中優化了數據的重復發送問題。

BDS Replication

流量切換

在具備主備集群的前提下，災難期間需要快速的把業務流量切換到備份集群。阿里HBase改造了HBase客戶端，流量的切換發生在客戶端內部，通過高可用的通道將切換命令發送給客戶端，客戶端會關閉舊的鏈接，打開與備集群的鏈接，然后重試請求。

阿里云同城主備

切換瞬間對Meta服務的沖擊：hbase客戶端首次訪問一個分區前需要請求Meta服務來獲取分區的地址，切換瞬間所有客戶端并發的訪問Meta服務，現實中并發可能在幾十萬甚至更多造成服務過載，請求超時后客戶端又再次重試，造成服務器一直做無用功，切換一直無法成功。針對這個問題我們改造了Meta表的緩存機制，極大地提高了Meta表的吞吐能力，可以應對百萬級別的請求。同時在運維上隔離了Meta分區與數據分區，防止相互影響。

從一鍵切換走向自動切換。一鍵切換還是要依賴報警系統和人工操作，現實中至少也要分鐘級別才能響應，如果是晚上可能要10分鐘以上。阿里HBase在演進自動切換過程中有兩個思路，最早是通過增加一個第三方仲裁，實時的給每一個系統打健康分數，當系統健康分低于一個閾值，并且其備庫是健康的情況下，自動執行切換命令。這個仲裁系統還是比價復雜的，首先其部署上要保持網絡獨立，其次其自身必須是高可靠的，最后健康分的正確性需要保證。仲裁系統的健康判斷是從服務器視角出發的，但從客戶端角度來講，有些時候服務器雖然活著但是已經不正常工作了，可能持續的FGC，也可能出現了持續網絡抖動。所以第二個思路是在客戶端進行自動切換，客戶端通過失敗率或其它規則來判定可用性，超過一定閾值則執行切換。

極致體驗

在風控和推薦場景下，請求的RT越低，業務在單位時間內可以應用的規則就越多，分析就越準確。要求存儲引擎高并發、低延遲、低毛刺，要高速且平穩的運行。阿里HBase團隊在內核上研發CCSMAP優化寫入緩存，SharedBucketCache優化讀取緩存，IndexEncoding優化塊內搜索，加上無鎖隊列、協程、ThreadLocal Counter等等技術，再結合阿里JDK團隊的ZGC垃圾回收算法，在線上做到了單集群P999延遲小于15ms。另一個角度上，風控和推薦等場景并不要求強一致，其中有一些數據是離線導入的只讀數據，所以只要延遲不大，可以接受讀取多個副本。如果主備兩個副本之間請求毛刺是獨立事件，那么理論上同時訪問主備可以把毛刺率下降一個數量級。我們基于這一點，利用現有的主備架構，研發了DualService，支持客戶端并行的訪問主備集群。在一般情況下，客戶端優先讀取主庫，如果主庫一定時間沒有響應則并發請求到備庫，然后等待最先返回的請求。DualService的應用獲得的非常大的成功，業務接近零抖動。

主備模式下還存在一些問題。切換的粒度是集群級別的，切換過程影響大，不能做分區級別切換是因為主備分區不一致；只能提供最終一致性模型，對于一些業務來講不好寫代碼邏輯；加上其它因素（索引能力，訪問模型）的推動，阿里HBase團隊基于HBase演進了自研的Lindorm引擎，提供一種內置的雙Zone部署模式，其數據復制采用推拉組合的模式，同步效率大大提升；雙Zone之間的分區由GlobalMaster協調，絕大部分時間都是一致的，因此可以實現分區級別切換；Lindorm提供強一致、Session一致、最終一致等多級一致性協議，方便用戶實現業務邏輯。目前大部分阿里內部業務已經切換到Lindorm引擎。

零抖動是我們追求的最高境界，但必須認識到導致毛刺的來源可以說無處不在，解決問題的前提是定位問題，對每一個毛刺給出解釋既是用戶的訴求也是能力的體現。阿里HBase開發了全鏈路Trace，從客戶端、網絡、服務器全鏈路監控請求，豐富詳盡的Profiling將請求的路徑、資源訪問、耗時等軌跡進行展示，幫助研發人員快速定位問題。

總結

本文介紹了阿里HBase在高可用上的一些實踐經驗，結尾之處與大家分享一些看可用性建設上的思考，拋磚引玉希望歡迎大家討論。

從設計原則上

• 1 面向用戶的可用性設計，在影響面、影響時間、一致性上進行權衡
  MTTF和MTTR是一類衡量指標，但這些指標好不一定滿足用戶期望，這些指標是面向系統本身而不是用戶的。
• 2 面向失敗設計，你所依賴的組件總是會失敗
  千萬不要假設你依賴的組件不會失敗，比如你確信HDFS不會丟數據，然后寫了一個狀態機。但實際上如果多個DN同時宕機數據就是會丟失，此時可能你的狀態機永遠陷入混亂無法推進。再小概率的事件總是會發生，對中標的用戶來講這就是100%。

從實現過程上

• 完善的監控體系
  監控是基礎保障，是最先需要投入力量的地方。100%涵蓋故障報警，先于用戶發現問題是監控的第一任務。其次監控需要盡可能詳細，數據展示友好，可以極大的提高問題定位能力。
• 基于隔離的冗余
  冗余是可用性上治本的方法，遇到未知問題，單集群非常難保障SLA。所以只要不差錢，一定至少來一套主備。
• 精細的資源控制
  系統的異常往往是因為資源使用的失控，對CPU、內存、IO的精細控制是內核高速穩定運行的關鍵。需要投入大量的研發資源去迭代。
• 系統自我保護能力
  在請求過載的情況下，系統應該具備類如Quota這樣的自我保護能力，防止雪崩發生。系統應該能識別一些異常的請求，進行限制或者拒絕。
• Trace能力
  實時跟蹤請求軌跡是排查問題的利器，需要把Profiling做到盡量詳細

阿里云雙11領億元補貼，拼手氣抽iPhone 11 Pro、衛衣等好禮，點此參與：http://t.cn/Ai1hLLJT

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里HBase高可用8年“抗战”回忆录的全部內容，希望文章能夠幫你解決所遇到的問題。

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