你好,游客 登录 注册 搜索
背景:
阅读新闻

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

[日期:2014-12-15] 来源:新浪微博  作者:@liudaoru [字体: ]
      自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稳定性保障体系:

原文出处:http://weibo.com/p/1001603786297964636689





收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款