HBase使用者福利
新使用者9.9元即可使用6個月雲資料庫HBase，更有低至1元包年的入門規格供廣大HBase愛好者學習研究，更多内容
請參考連結前言
2011年畢玄和竹莊兩位大神将HBase引入阿裡技術體系，2014年接力棒轉到東8區第一位HBase commiter天梧手中，多年來與淘寶、旺旺、菜鳥、支付寶、高德、大文娛、阿裡媽媽等幾乎全BU合作夥伴攜手共進，支撐了雙十一大屏、支付寶賬單、支付寶風控、物流詳情等核心業務。2018年雙十一，HBase全天處理請求2.4萬億行，單叢集吞吐達到千萬級别。從一個嬰兒成長為青年，阿裡HBase摔過很多次，甚至頭破血流，我們在客戶的信任之下幸運的成長，感激涕零。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%。
從實作過程上
1 完善的監控體系
監控是基礎保障，是最先需要投入力量的地方。100%涵蓋故障報警，先于使用者發現問題是監控的第一任務。其次監控需要盡可能詳細，資料展示友好，可以極大的提高問題定位能力。
2 基于隔離的備援
備援是可用性上治本的方法，遇到未知問題，單叢集非常難保障SLA。是以隻要不差錢，一定至少來一套主備。
3 精細的資源控制
系統的異常往往是因為資源使用的失控，對CPU、記憶體、IO的精細控制是核心高速穩定運作的關鍵。需要投入大量的研發資源去疊代。
4 系統自我保護能力
在請求過載的情況下，系統應該具備類如Quota這樣的自我保護能力，防止雪崩發生。系統應該能識别一些異常的請求，進行限制或者拒絕。
5 Trace能力
實時跟蹤請求軌迹是排查問題的利器，需要把Profiling做到盡量詳細