新浪微博对HBase在线业务稳定性保障的一些思考

日期： 2014-12-11 作者：@liudaoru 来源：TechTarget中国 英文

自2012年微博平台在本厂率先使用HBase做在线业务以来，HBase目前已在本厂广泛使用，最大的集群单集群就有三四千亿条记录。当然我们也在HBase在线服务的稳定性方面遇到一些挑战，前一段时间也总结了一篇从应用层面进行稳定性保障的思路，但近期的实践和思考发现仅从战术、应用层面去防御是不足的，HBase稳定性保障需要全方位的防御建设。
首先看看HBase相比Mysql、Redis等有何差异点：
  1. 以Java构建，内部实现相当复杂，本厂几位读源代码的同学都没能搞定；
  2. Client 过于厚重，实现比较封闭，没办法进行定制扩展开发，前段时间我们做HBase Fail Fast机制时就吃了大亏；
  3. 内部组件状态不透明，各个组件的关联关系相当复杂，某一模块出问题就可能导致全局出问题；
  4. 服务恢复复杂，各个组件之间有比较多的关联；
  5. 由于数据量较大，有的集群恢复时间以天为单位，对服务影响较大，前端稳定性配合的难度也比较高；
以上特点导致虽然我们持续投入了众多主力干将，但掌控水平仍然不够理想。而拆解这些问题之后会发现这些问题还是有解决方案：
  1. 单集群规模过大，这时瓶颈是带宽和磁盘速度，其解决方案只能是保持集群规模，否则只能祈祷集群整体不要出问题。虽然HBase提供的是一体化的解决方案，但为了确保服务故障时能够快速恢复，还是要控制单个集群的规模，必要时要对集群进行拆分；
  2. Client实现复杂的问题，如果代码嵌入不进去，那么就当个黑盒用，我们的Fail Fast就是当做黑盒，从近期几次问题来看，效果还是很理想；
  3. 对代码体系掌控不足的问题，对于这么一个复杂的问题，第一步应该是先掌握最简单的模型，然后逐步去了解周边的各种功能模块；
  4. 对于修复复杂的问题，可以用最经典的解决方案：“重做整个集群”，如果面对一个棘手的问题重做是更优的解决方案；
做到如上的点，我们HBase的稳定性保障已经会大大提升，但由于HBase只能部署在单个机房，如果这个机房网络故障，则也会影响整个服务，这时我们便可用多集群部署的解决方案，如下图：

如上的解决方案在资源上会有一些冗余，但如果应用在核心服务则可以确保服务有非常高的可用性保障。相比于Mysql的解决方案，按2000亿条数据（恢复时间在24小时左右，业务能忍受的极限）一个集群算，集群内的容量线性扩容，依然是一个很好的万亿级数据的解决方案。

最终我们可以总结出如下的HBase稳定性保障体系：

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。

相关推荐