很長一段時間以來，一個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。

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