1. 程式人生 > >淺析HBase region的單點問題

淺析HBase region的單點問題

mas 思路 沒有 分布式 atan 磁盤 額外 行數 目前

很長一段時間以來,一個region同一時間只能在一臺RS(Region Server)中打開。如果一個region同時在多個RS上打開,就是multi-assign問題,會導致數據不一致甚至丟數據的情況,這是要避免和解決的。對於正常情況而言,region本質上是單點服務的,當RS宕機時,這個RS上的region無法提供服務,直到他們在另外的RS上重新上線為止。我們首先討論這種單點服務會導致哪些問題,然後,看看有什麽解決方案。

region單點導致的問題

從正常和異常兩個方面對region單點可能導致的問題進行分析。因為region只在一臺RS上assign,那這臺RS直接決定了這個region的服務質量,RS發生的任何問題或多或少都會對region產生影響。

對於RS日常工作時出現的各種問題,導致的region服務質量問題,我們可以簡單的將其稱為“抖動”。包括:

  • 非人為因素(不可預期的)
    • GC問題:GC一直是java應用的老大難問題,尤其是對HBase這種高吞吐的後臺系統,更是需要優化到極致
    • 網絡問題:TCP重傳,丟包,closewait過多,隊列滿,網絡硬件問題等等,都會導致RT升高或者請求超時
    • 磁盤問題:壞盤,慢盤,io排隊,通常會同時影響讀和寫。單個datanode變慢甚至會影響整個hdfs集群
    • 其他硬件或操作系統問題:cpu,內存,系統時鐘,OS內存管理,任何部件出現問題都會導致RS抖動
    • 同RS的其他region有問題:有些region有問題,可能會把RS打爆,從而這個RS上所有的region都被影響了
  • 人為因素(可預期的)
    • balance:手工move/split/merge region,會導致短暫的服務停止
    • 擴容/縮容:會產生大量的region move操作
    • 升級:不同的升級手段會有不同的影響,通常比較溫柔的升級策略都是把RS上的region移動到其他機器上,然後再重啟。而不是直接暴力重啟
    • 誤操作:這個就多了。。。

硬件和OS的問題可以暫時丟在一邊,region本身的操作在高吞吐場景下會帶來非常明顯的影響。例如region做flush,意味著memstore的snapshot操作會鎖住所有的請求。此時,新到達的讀寫請求會被阻塞,直到正在執行的讀寫請求全部完成。如果單個請求的平均執行時間都非常短(1ms至幾個ms),那整個region鎖住的時間也可以非常短;如果有比較大的batch寫,或者scan,那鎖住的時間就會變長,從而對單region的整體吞吐產生極大的影響。

考慮到HBase的設計目標是少量的大表,一個大表通常有很多的region(少則數百,多則幾十萬),單個region的吞吐被影響對於整體而言,通常不會導致明顯的流量波動。但如果一個表有相當比例的region出現同時無法服務的情況,則這個影響就無法忽略。一個典型的場景就是修改表屬性。比如修改壓縮或者ttl之類的,此時master會對表的所有region進行批量reopen。同時有十幾到幾十個region在做reopen是非常正常的。

另外,如果是RS有問題(硬件問題,或者RS被某些region打爆了),則這個RS上所有的region會同時被影響。這時,影響域就會擴大,甚至產生連鎖反應。比如一個以寫吞吐為主的日誌型或者監控型業務,通常都是大batch寫入。一個batch寫操作通常會寫多個RS,那一個RS慢了,整個batch都會被拖慢。從而導致客戶端排隊,GC加重,整體吞吐下跌。

上面我們討論的都是RS日常工作中可能發生的問題,下面我們看一下RS宕機時的情況。RS的宕機處理的簡要流程如下:

  • master檢測到RS宕機:zk臨時節點超時,通常要30秒-1.5分鐘
  • 故障RS上的region重新assign到其他RS,很快,幾秒
  • HLog的split和replay:1分鐘或者更長,取決於有多少數據要replay,以及集群的規模

一個比較難理解的事情是宕機檢測居然需要這麽久的時間。為什麽zk超時時間要設置這麽長?設置成幾秒不行嗎?這裏主要的考慮是RS可能會假死,一個典型的假死場景就是RS發生FGC。對於比較大的堆,一次FGC做個幾十秒甚至數分鐘都是有可能的。如果zk超時設置過短,一次幾十秒的FGC就可導致RS“被宕機”。而RS從FGC中恢復後,可以立即服務,但如果被認為是宕機,那後續的處理時間會更長,影響更大。

對於region的單點assign,從RS實際發生宕機到宕機處理完畢,通常需要數分鐘甚至更長的時間,在這段時間裏,故障機器上的region都無法提供服務。雖然HBase能夠在宕機時能夠自動恢復,但宕機帶來的影響是確實存在的,對於業務來說,往往幾分鐘的不可用時間就足以帶來困擾(比如網絡遊戲,服務器卡一下你都不能忍,更不要說卡幾分鐘了)。

可能的解決方案

對於抖動和宕機導致的region服務質量下降,我們可以有兩個思路:

  • 優化系統,減少抖動和宕機處理時間:
    • 比如優化GC,系統參數調優,使用更高配置的機器和網絡,將HDD更換為SSD
    • 減少宕機檢測時間,優化log split和replay,提高速度。
  • 副本(冗余),一個reigon有問題時,切換到該region的其他副本中

第一條是必須做的,因為抖動問題就像卡在喉嚨裏的一根魚刺,沒有問題還好,一旦有問題,就讓你疼的不行,甚至還會流點血。不小心紮破頸部大血管,就要打110了。減少宕機恢復時間是有上限的,在當前的硬件體系和能力下,軟件做的再好通常也不能在幾秒的時間裏處理完宕機。所以,必須訴諸於副本方案。一個典型的副本方案就是主備集群。兩個集群互為主備,一個掛了就切另一個。一般可以做到秒級檢測和切換。但雙集群部署會增加額外的成本,所以,HBase 1.x系列提供了單集群的冗余策略,region replica方案,即一個region同時在多個RS上打開,有主備,一寫多讀。原理上跟mysql的一寫多讀是類似的。

多副本方案要解決的難題就是一致性問題。目前比較常見的是基於paxos或者raft的一致性算法,在多個副本之間進行數據同步,比如tidb。

從長遠來看,第一條是每個分布式存儲系統的長期任務,第二條是現代系統要做到高可用所必須具備的能力,或者說目前的技術水平下,可以商用的最好方案。原理都差不多,各家拼的就是工程實現的優劣,即成本,一致性和性能。

淺析HBase region的單點問題