线上服务假死解决

问题描述

高峰期线上服务出现假死，查看内部服务发现微服务其中一个模块出现无响应，一段时间后回复正常

排查

一出现服务崩溃大家脑海里面可能都会出现内存泄露，数据库cpu爆满、 慢sql等等，但这次确有所不同。
通过性能监控发现CPU比平时稍高多占用两核，内存正常 数据库cpu比平时稍高没出现爆满情况 。
通过查看GC状态也正常

jstat -gc pid

分析

凡事预则立，通过已有排查信息，得出不存在内存泄露，数据库cpu爆满、 慢sql等这些情况。并且服务在一分钟后会自行恢复，那么可以猜测出在服务不可用的时间节点有大量的请求线程正在执行，通俗的理解就是被流量打死了。

验证

张三说过，人这一辈子很难逾越的鸿沟就是说与做的距离。接下来就是验证猜想了，被流量打死最终要落实到业务上，排查发现这个时间节点哪块业务最频繁，通过查看数据库的执行次数可以得出最频繁使用的业务。
可以通过DruidDataSource的监控工具等查看
因本次使用的事阿里云RDS，最终排查处一个sql中占比50%，单次查询耗时5ms，但因使用的or未走索引，type级别为ALL 全表扫描
猜测成立

解决方案

1.优化业务查询占比
2.优化sql

执行sql去掉or拼接改成union，建立索引

结果

高峰期业务运行正常，业务查看sql占比下降，语句执行type级别降为ref级别，执行耗时无限接近0ms。

后续带来内存泄露、慢sql等案例