慢查询导致整个服务不可用的预防及解决办法

losetowin 发布于:2016-9-20 20:12 分类:技术  有 902 人浏览,获得评论 0 条 标签: 慢查询 服务不可用 柔性服务 服务降级 

本文地址:http://www.dutycode.com/manchaxun_fuwu_bukeyong_yufang_ji_jiejuebanfa.html
除非注明,文章均为 www.dutycode.com 原创,欢迎转载!转载请注明本文地址,谢谢。
现象:
DB层服务短时间内涌入大量的慢查询,并且查询的数据量比较大(2000w+,查询字段未添加索引)导致服务不可用,出现mysql查询超时现象
3ABA9400-D312-4310-805C-12797889ECF0.png

分析:
数据库操作时误将查询条件的字段的索引去掉了,导致原有的查询效率降低,产生慢查询。

解决:
对相应字段添加索引,慢查询消失,超时现象消失。

反思:
1、突然出现的慢查询导致服务不可用这种事情该如何避免?
     1)、事件的起因是因为误操作,限制操作人员的行为,约定不可随意变更数据库的索引。这种方式不可行,原因在于一旦需要人为介入且为主观性的操作,就无法保证不再出错误。所以,需要寻找一种机器(自动)的方式来帮助发现问题或者解决问题,机器是不会偷懒的。
     2)、有以下几个出发点:
          a、监控:
               监控在于可以尽早主动发现问题,而不是被动的被告知说出现问题了,这时候,可以人为介入排查原因并修复(PS:这个地方的人为介入和上面提到的不太一样,这个是指解决问题的人为介入,而第一条指的是发现问题和避免问题的人为介入方式)
          b、主动防御:
               目的在于保护服务不至于被部分异常请求拖垮,进而产生滚雪球式的服务不可用。
               有几个解决办法:
                    i:db层服务,对sql执行时间做监控,如果查询时间超过预设值,则记录为可疑查询,如果标记次数超出上限值,则限制此类SQL的查询,并告警周知相关人员。 (PS:数值设定需根据业务来设定,此类操作为业务相关,非架构层面需要关注的点)         
                         但这样存在一定的风险:因为是服务主动性的阻止某些查询, 可能会误杀正常的查询(比如,大事务的查询,本身需要耗时很久),所以这种方式需要做下权衡。
                    ii:限流,限制请求流量。 
          c、主动防御的方式,只能保证不至于被异常情况导致服务可用性为0。并未解决根本问题,所以更多的应该从服务角度去优化服务。提升系统的吞吐能力。
                比如,如果系统中存在慢查询,则应该是去分析慢查询的原因:
          1. 单表就是数据量大了,结构复杂,需要拆分
2. 关键查询条件缺少有效索引
3. 查询条件复杂,有数据移动(跨表或者跨库操作),需要调整查询逻辑
4. 有大事务
          d、如果作为服务调用方,需要考虑的是,如何去做服务降级,如果某个服务不可同时,不至于影响整个系统的可用。

2、类似的导致服务不可用的情况或者导致系统吞吐量下降的情况还有哪些?

     比如: 缓存雪崩—>缓存大面积失效、缓存服务器突然宕机等会导致请求落到后端DB上,导致DB压力过大,产生服务不可用。

备注:上面的解决办法仅是思路,尚未在实际中使用,仅供参考使用。 

版权所有:《攀爬蜗牛》 => 《慢查询导致整个服务不可用的预防及解决办法
本文地址:https://www.dutycode.com/manchaxun_fuwu_bukeyong_yufang_ji_jiejuebanfa.html
除非注明,文章均为 《攀爬蜗牛》 原创,欢迎转载!转载请注明本文地址,谢谢。