1.问题起因
最近工作中遇到个问题,开始是凌晨的一段时间,线上业务频繁报警,后来查询CAT和日志,发现是由于一个名为selectByOrderId的慢查询导致的。
遇到这种情况,通常会想到加索引。但是查看数据了解业务之后,发现这张300W数据表中只有几十条该字段非空,且会较频繁更新。于是想进一步分析,看看有什么其他的解决方案。
再看long-url,有一个用于客户端上报支付结果的report接口占比非常大。
数量上差不多,会不会有什么联系呢?翻了翻代码,发现report接口的处理逻辑确实有调用selectByOrderId相关rpc的代码,从这两张图来看,selectByOrderId慢查询仿佛大部分是由report接口导致的,但是什么样的参数会导致慢查询还需要进一步分析。
正好最近有点迷机器学习,学了点Python数据分析的皮毛,就用这个练练手吧。
2.着手调查
2.1 目标
找到report接口响应时间过长的共性
2.2 数据准备
在服务器上拉取了包含report接口的api日志,日志格式为"$requestId $json",在json格式中存储了接口名称、输入参数、输出参数、状态码、发起时间、耗时、用户设备等40多项信息,并且有多层嵌套。
使用awk、sed将数据提取成json数组的形式:
# 删除requestId并使用在行尾添加,分割json串。由于json中可能有空格,所以