HBase Bug 知多少

可以带着下面小问来看本回帖：
1、HBase的概念、原理是什么
2、HBase的bug有哪些

针对第一个问题
即HBase的概念以及原理，请参考该贴


下面我们来讲第二个问题

HBase的应用愈加广泛，例如HBase在阿里集团大规模使用已经有一年多时间了，随着online应用越来越多，对HBase的稳定性、实时性、可维护性要求越来越高。在业界HBase的发展也越来越快，很多人都还有疑惑：HBase真的靠谱么？在核心应用能大规模使用么？下面就从测试的角度，分析下发现的bug。

HBase Bug 知多少

到目前为止，共发现bug328个，其中Blocker 34个，Critical 41个，Major 205个， Minor 48个。从数字上看bug的确很多，但并不是说HBase不稳定，通过这么多bug的fix，我们解决了非常多极端小概率场景、异常场景的问题，预防了很多bug的上线，丰富了工具、日志、监控、运维工具等等，使得HBase稳定性提高到了新的高度。

HBase 哪里最不靠谱

HBase的开发、测试、运维人员以及用户，恐怕最关心的就是HBase到底靠不靠谱，哪里问题最多。。

1、region assign：region分配相关，由于是分布式事务，在异常情况下出现bug的概率很高，也是发现bug最多的部分，常见故障为region二次分配、长时间不分配、ROOT META表分配异常、master多个处理线程冲突等。可以导致region无法服务或者数据丢失。

2、compact：compact部分总体上看是相当稳定的，由于实现较简单并没有太多bug，淘宝在compact方面加入和很多策略（多线程、错峰）来适应线上系统的需求。

3、split：bug重灾区，原因也是由于他是个一个复杂的事务，并且需要回滚。在0.90中我们还无法完全弃用split，因此这些bug必须得到修复而不能通过运维来避免，目前已经相当稳定。

4、flush：实现较为简单，在控制部分有些bug。

5、correctness：读写行为的正确性，是HBase最为核心的部分，目前官方0.90和0.94版本都有部分正确性问题的bug，尤其是0.90版本中读写原子性上还有问题，但是出现概率很低，场景也较为极端，一般应用很少会遇到。在后续版本也考虑进行彻底的fix。社区现在还没有打算在0.90上彻底修复。

6、wal：日志是HBase的核心功能之一。常见bug存在于分割日志和恢复日志两部分，导致数据恢复不正确及数据丢失。另外在线上日志分割速度也是故障影响时间的决定因素，在这方面也投入了不少精力进行测试和优化，目前已经有了非常理想的效果。

7、ddl：HBase中常用ddl操作是create table、disable、enable、alter。在进行这些ddl操作时如果系统发生异常很可能无法得到正确的处理，目前社区也没有修复完毕。

8、abort：HBase中有很多异常发生都会导致server abort，尽量缩减和避免这些场景发生也是保证系统稳定的一大手段。因此做了不少修改避免了不应该发生的abort行为，并且修复了abort行为发生后的一些bug。

9、zk：0.90版本中针对zk发生异常的处理很弱，基本可认为无抵抗力，在0.94社区已经做了较多改进。但是从测试情况来看，过度依赖zk还是会被zk的一些自身问题牵绊，导致系统不稳定。

10、client：总体上说client还好，使用0.90.6以后版本和0.94.2都能保证较高的稳定性。0.94前期版本含有较多致命bug，还需要慎重使用。

11、replication：HBase自带的replication部分不是很满足一些应用的需求，对这部分做了较多重构，目前还在准备上线中。

12、gc：gc的bug主要来自不适合的gc配置引起的fullgc或者gc频繁。出现fullgc后系统会有一些不稳定的地方，在代码上做了一些保障来防止发生fullgc对系统的致命影响。

13、testcase：接触HBase单元测试的同学肯定会发现其实官方提供的case很多并不稳定。

14、tools&other：主要是一些运维工具和脚本、监控、日志等。为了加强HBase的可运维性，淘宝做了很多建设性的事情，比如建立了完善的监控体系，而且正在建立一套trace工具来跟踪一些可疑请求以及分析线上系统性能。

从线上看Bug

对于HBase这种存储系统来说，对外接口相对单一，但是内部实现较为复杂。这种特性决定了发现bug的多数都是小概率问题，因为容易出现的问题在用户使用时都已发现，往往也较容易修复。稳定性并不是一天做出来的，不放弃任何一个小问题才能保证真正的稳定，希望与各位同仁共同努力。