HBase 异步查询导致的死锁和zookeeper通信中断问题追踪与总结［非技术］

go4321

　　机房T和机房Y共十台前端机，Y机房请求量是T的两倍，主要用于数据查询，开始问题是Y机房tomcat 相继僵死
　　1） tomcat僵死处理步骤
　　a 检查代码，发现read through后，没有把DB数据写到缓存，增加回写代码；但单台机器每秒请求也就几十条，HBase压力很小，最终发现无效。
　　b 检查代码，认为跟运行几个月的动态代码在HBase使用上完全一致，所以认为业务代码层没有问题；打印堆栈信息，认为是HBase client端发现资源等待死锁的问题
　　c 下载0.94.2 patch，分析认为其解决了死锁问题，更新jar包部署。
　　
　　第二周发现tomcat 日志疯狂报Interrupted错误，进程没有僵死，但有大量查询超时，达100秒，firelog每3分钟单台5000＋慢查询
　　2） 超时处理步骤
　　a 认为0.94.2没有能解决问题，只是避免了死锁，但会导致Interrupted异常；使用liwei打的0.94.2的patch包上线，发现启动失败，未果（jar包中缺少版本信息，无法启动）
　　b 比较两个机房差异，认为Y机房网络有问题，ping HBase资源测试没有发现问题，晚上停掉T机房3台服务器，负载全在剩余两台上，达到请求量的平衡；当天晚即发现T机房也出现异常及大量超时；网络问题排除
　　c 第二天由于产品压力，召集开发和DBA封闭解决问题。启动tcpcopy环境做测试，尽快重现问题。计划了四个方案
　　1. 0.94.0 打patch上线
　　2. tcpcopy测试0.94.2 Interrupt问题
　　3.线程池去掉timeout，即不使用异步；使用后台线程2分钟检查一次HBase client的zookeeper watcher，看能否得到数据，出现问题则重新设置zookeeper；设置retry number为3次，避免重试10次，每次时间加倍导致超长查询
　　4.升级zookeeper jar版本
　　尝试到第三个版本终于正常，10点上线，十一点无状况，部门人员观察到2点，没有问题，第二天的数据统计99.92％请求200ms以下。通过规避异步timeout任务，不和HBase的默认异步调用发生冲突，从而解决了问题，需要从根本上做研究，彻底了解清楚原理。
　　总结一下，在四个方面处理有问题，需要改进
　　1. 网络问题  没有及早做不同机房的流量压力测试，tcpcopy测试
　　2. 代码逻辑问题；因为动态运行了几个月没问题，新代码跟旧代码读取部分没有差异，因此错误排除了自身问题，将问题归结于HBase client 代码。
　　3. 问题评估：没有评估出问题严重性，超时比率，导致最终服务恶化。
　　4. 人力投入问题：应早投入人力分析处理，而不是出现完全无法支撑，高层都投诉的情况下才召集处理。