异想天开

What's the true meaning of light, Could you tell me why

这也算bug

日期:2015-01-11 18:24:43
  
最后更新日期:2015-01-30 14:26:08
【技术文章】
周末这两天一直收到警报,公司运维昨天周六打了一次电话,当时周五的时候,就收到警报邮件,当时看到的直接原因是两台后端的cpu负载极端不均,一台近300%,另外一台0%。这已经是线上运行的服务。周五的时候在后端机器查询少数次数正常,当时以为就是负载高,程序的性能hold不住。下午吃过中饭,送了一个离职回家的前同事,跑来公司,读代码,读了大概半小时左右,期间邮件还是收到两台前端偶尔间隔2~3分钟一次的警报。后面想自己改监控的查询参数,查询命中不同的后端,查看不同后端从前端得到的访问结果,因为后端本地的监控是正常的。这种如何命中后端就需要去看前端程序的配置文件,以便根据我们的hash方法命中后端。这时发现了问题,居然配置文件里面与后端的映射的配置搞错了。奇葩问题。根据配置文件的映射,相当于只有一台后端在服务,另外一台没有被映射。难怪负载接近0%。PS:由于后端程序去掉了debug日志,协议又是二进制协议,所以当时也没有日志可以看。
理智点来看这个问题。当只有一台后端服务时,后端处理不过来,所以前端会有超时。后端程序处理不过来时,cpu负载只为300%左右。也就是遭遇了性能瓶颈。这瓶颈没有解决的必要,我的想法是,瓶颈的单机的优化需要耗费大量时间。心里有套替换的方案-nginx+redis,当请求过多时,后端首先利用某个参数水平扩展hash到不同的节点的redis,当某个节点的redis请求还是hold不住时,那么可以用redis主从模式,缓冲一样的内容,扛住hash过来的压力。PS:由于业务要求,改动同时牵扯到另外一个程序也需要改动,加上又有了需求,bug要解,所以才放一放。