线上cpu报警的一次接口优化

悠悠 2023-09-25 22:16 30阅读 0赞

## 前言 ##

春天到了大地都复苏了，沉寂了很久的cpu也开始慢慢复苏了，所谓前人埋坑后人填坑，伴随着阿里云监控报警，线上CPU使用率暴增，于是就开始了排查之路。

![format_png][]

## 出现问题现象 ##

由于服务的cpu暴增到达一定程度，导致服务假死，接口调用全部返回502不可用，链接超时导致服务器方面无法给予正常的反应。

![format_png 1][]

通过查看阿里云数据库RDS，慢sql日志进行分析，发现数据库的CPU使用率在某一时间到达了96%，这不完犊子了。

![format_png 2][]

导出监控平台分析的慢sql，看到这个sql平均的执行时间，真的是再次刷新了我的认知，平均执行法时间2分多钟，这怕是执行的黄花菜都要凉了。

![format_png 3][]

## 问题排查 ##

首先根据阿里云分析的慢sql进行再次分析，sql肯定是有问题的，而导致服务不可用的原因还需要看微服务的负载配置，于是我去查看了该服务Nacos的配置。这里我们看到该服务Ribbon超时时间为15妙，就意味着接口如果执行超过这个时间接口就无法继续执行，从而出现服务假死不可用的现象。

服务接口调用长时间没有反应，ribbon负载均衡会触发熔断机制，对服务进行保护，让服务不可调用。

![format_png 4][]

### 涉及接口 ###

通过慢sql对应到问题接口，对接口逻辑进行梳理，排查接口涉及到的sql。 通过对业务逻辑分析，发现这个接口对慢sql执行了两次，一次是正常分页查询数据，第二次是没有加分页参数，那么将全表查询，对查询的结果根据字段进行过滤，过滤出count条数。

![format_png 5][]

![format_png 6][]

其次是发现前端对这个接口进行两次调用，咱也不知道为什么，但是在请求上看来，访问该页面同一接口确实进行两次调用，本来接口就很慢了，这简直就是一个暴击。

![format_png 7][]

### 慢sql分析 ###

因为动态sql比较长，我只挑选我认为sql不是很合适的地方

1.  查询列中用select嵌套查询

![format_png 8][]

2. sql中出现大量字段in的查询

In是走索引的查询，但是当in括号里面的条件比较多的情况下，就是传入的参数这个list列表长度比较大的情况下，是不走索引的，会进行全表扫描，in最终走不走索引其实是跟后面的数据有关系的。

![format_png 9][]

1.  表中数据量 主表大概在25w多数据，关联表比较大在170w数据。 主表索引加了很多，未必就是一件好事，索引的设置完全按照搜索条件来设置也未必对，涉及到关联表一定要添加索引。

![format_png 10][]

关联表出现了很多重复数据，因为不了解之前业务的逻辑，不太清楚为什么出现很多重复数据，这也是表中数据量很大的原因，从而导致影响查询效率。

## 接口优化 ##

既然现在问题找到了，就可以进行优化了，我说下我优化的思路，主要是从下往上进行优化。

1.  慢sql优化，主要是针对嵌套查询改为left join 左外联查询，减少了in查询，查询出来的数据在代码中进行筛选，减少了一些不必要的索引。

![format_png 11][]

1.  通过conut(*)统计需要的条数，在所有count里面，count(*)是效率最高的了，有兴趣的朋友可以去了解下。

![format_png 12][]

3. 业务代码方面，限制了时间筛选的区间，从原来的不限时间勾选范围，跟业务进行沟通后，调整为只允许选择一周的时间范围进行查询，前后端都进行限制。

![format_png 13][]

## 优化结果对比 ##

由此可见优化后的执行效率还是比较高的，线上服务也没有在报警了，但是还有其他服务在报警…. 还有磁盘使用率到达90%…. Wtf真的是优化之路途漫漫啊。

![format_png 14][]

![format_png 15][]

## 总结 ##

此次对于接口的优化点还不是很深，主要点是对代码、sql、业务进行优化，还未涉及到分表、加入缓存热点数据进行预热、修改负载均衡超时时间等… 其实偶尔的填坑也是一种学习的方式，不说了继续填坑了，哦！不对优化代码了～

[format_png]: https://img-blog.csdnimg.cn/img_convert/eafcf9a0dbf0a81bae715520e65d2028.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/03cf7dae50b4c3bb1858a558affb2d6f.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/9bb91ebbeb1db8112a1d5ef3d08bdf7f.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/56f8f015e19aac4576e37c3c1cd82f18.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/f22007c508faf07cd7f093ecd5aae29e.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/b1eb026b076339f84fbc5c0e3ddb641b.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/31f1b1af446b181b17b5ebfb35e988ba.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/8bab5868c4c9b938c591ec0bcf451945.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/04ff21495af79e613479e26b6a31b3c9.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/cc8f8ec42ab1a958dd4fa0ea881cdad2.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/b7859b486b0d38a4edbe96a82ca6f6aa.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/ddbd45404c1d07904f5e8ac10dff4d07.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/fbbf486cf3473e661093d02f7757dda5.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/84e719646344df8be27a7c4789b17dc5.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/fc13a4b3611310b68fcbe9d04a7bf508.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/d5e222dce6a1465bd7b88703ac29f474.webp?x-oss-process=image/format,png