目录
- 背景
- 哪些问题会引起接口性能问题
- 问题解决
- 总结
背景
我负责的系统在去年初就完成了功能上的建设,然后开始进入到推广阶段。随着推广的逐步深入,收到了很多好评的同时也收到了很多对性能的吐槽。
刚刚收到吐槽的时候,我们的心情是这样的:
当越来越多对性能的吐槽反馈到我们这里的时候,我们意识到,接口性能的问题的优先级必须提高了。
然后我们就跟踪了 1 周的接口性能监控,这个时候我们的心情是这样的:
有 20 多个慢接口,5 个接口响应时间超过 5s,1 个超过 10s,其余的都在 2s 以上,稳定性不足 99.8%。
作为一个优秀的后端程序员,这个数据肯定是不能忍的,我们马上就进入了漫长的接口优化之路。本文就是对我们漫长工作历程的一个总结。
哪些问题会引起接口性能问题
这个问题的答案非常多,需要根据自己的业务场景具体分析。
这里做一个不完全的总结:
- 数据库慢查询
- 业务逻辑复杂
- 线程池设计不合理
- 锁设计不合理
- 机器问题(fullGC,机器重启,线程打满)
- 万金油解决方式
问题解决
| 慢查询(基于 mysql)
①深度分页
所谓的深度分页问题,涉及到 mysql 分页的原理。通常情况下,mysql 的分页是这样写的:
select name,code from student limit 100,20
复制代码
含义当然就是从 student 表里查 100 到 120 这 20 条数据,mysql 会把前 120 条数据都查出来,抛弃前 100 条,返回 20 条。
当分页所以深度不大的时候当然没问题,随着分页的深入,sql 可能会变成这样:
select name,code from student limit 1000000,20
复制代码
这个时候,mysql 会查出来 1000020 条数据,抛弃 1000000 条,如此大的数据量,速度一定快不起来。
那如何解决呢?一般情况下,最好的方式是增加一个条件:
select name,code from student where id>1000000 limit 20
复制代码
这样,mysql 会走主键索引,直接连接到 1000000 处,然后查出来 20 条数据。但是这个方式需要接口的调用方配合改造,把上次查询出来的最大 id 以参数的方式传给接口提供方,会有沟通成本(调用方:老子不改!)。
②未加索引
这个是最容易解决的问题,我们可以通过:
show create table xxxx(表名)
复制代码
查看某张表的索引。具体加索引的语句网上太多了,不再赘述。不过顺便提一嘴,加索引之前,需要考虑一下这个索引是不是有必要加,如果加索引的字段区分度非常低,那即使加了索引也不会生效。</