浅析HBase region的单点问题
很长一段时间以来,一个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。
从长远来看,第一条是每个分布式存储系统的长期任务,第二条是现代系统要做到高可用所必须具备的能力,或者说目前的技术水平下,可以商用的最好方案。原理都差不多,各家拼的就是工程实现的优劣,即成本,一致性和性能。