浅谈HBase region的单点问题

原文链接：

https://www.cnblogs.com/yhxx511/p/9609765.html

很长一段时间以来，一个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。

从长远来看，第一条是每个分布式存储系统的长期任务，第二条是现代系统要做到高可用所必须具备的能力，或者说目前的技术水平下，可以商用的最好方案。原理都差不多，各家拼的就是工程实现的优劣，即成本，一致性和性能。

一个进阶的大数据技术交流学习公众号，死磕大数据与分布式系统，分享NoSQL数据库、存储计算引擎、消息中间件等。长按二维码关注 ：