前言
接口性能优化对于从事后端开发的同学来说,或加个索引就能解决问题,或需要做代码重构,或需要增加缓存,或需要引入一些中间件,比如 mq,或需要分库分表,或需要拆分服务。。。
导致接口性能问题的原因千奇百怪,不同的项目不同的接口,原因可能也不一样。
我们一起来讨论以下行之有效的优化接口性能的办法:
1.索引
接口性能优化最先想到的可能是:优化索引
,因为其优化成本是最小的,可通过查看线上日志或者监控报告,筛查出某个接口调用的某条SQL语句耗时问题。
排查时一般从以下几点进行:
-
SQL语句加索引了没?
-
加的索引生效了没?
-
mysql 选错索引了没?
1.1 无索引 情况下
在项目中很常见的问题:SQL语句中忘了where
条件的关键字段,或者order by
后面的排序字段加索引。
项目初期由于表中的数据量小,无索引 SQL查询也不会引起大的性能问题。
但随着业务壮大,表中数据量越来越多,就不得不加索引了。
show index from `table_name`;
能单独查看某张表的索引情况。
show create table `table_name`;
查看整张表的建表语句,里面也会展示索引情况。
如果无索引,则可以通过ALTER TABLE
命令,或者CREATE INDEX
命令添加索引:
ALTER TABLE `table_name` ADD INDEX idx_name ( field_name );
或者
CREATE INDEX idx_name ON `table_name` (field_name);
目前在 mysql 中,想要修改索引则只能先删除索引后,再重新添加新的索引。其中删除索引方式有2种:ALTER TABLE
命令、DROP INDEX
命令
ALTER TABLE `table_name` DROP INDEX idx_name;
或者
DROP INDEX idx_name ON `table_name`;
1.2 添加的索引没生效
show index from `table_name`;
通过查询得知有索引,但它生效了没?如何进行查看索引有没有生效呢?
explain select * from `table_name` where code='002';
是的,用explain
命令来查看 mysql 的执行计划,它会显示索引的使用情况。
这几列就可以判断索引使用情况:
那么你知道索引失效的常见原因吗?
如果上面2个都没问题,则需要进一步排查其他原因。
1.3 选错索引
常常有这种情况:同一条SQL,只有入参不同而已,但有时走的索引 a,有时却走的索引 b?
必要时则可用force index
来强制查询SQL走某个索引。
现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:691998057【暗号:csdn999】
2. SQL 优化
如果优化索引后也对性能改变不大,则试着优化一下SQL语句,在这列举了 SQL优化的小技巧,共15种:
3. 远程调用
很多时候,我们需要在某个接口中,调用其他服务的接口。
有这样的业务场景:
用户信息查询接口中需要返回:用户名称、性别、等级、头像、成长值、积分等信息。
而用户名称、性别、等级、头像在用户服务中,成长值在成长值服务中,积分在积分服务中。为了汇总这些数据统一返回,需要另外提供一个对外接口服务。
这种业务场景下,我们就需要在某个接口中,调用其他服务的接口,即用户信息查询接口需要调用用户查询接口、成长值查询接口和积分查询接口,然后汇总数据统一返回。
如此计算,串行调用接口总耗时200ms + 150ms + 180ms = 530ms。
针对该情况,如何优化远程接口性能呢?
3.1 并行调用
既然串行调用多个远程接口性能很差,那我们可以改成并行调用:
这样则只需要取即耗时最长远程接口调用。
4. 重复调用
重复调用
在代码中如果没有控制好,会非常影响接口的性能,此时应减少代码运行重复。
5. 异步处理
接口性能优化,需要重新梳理一下业务逻辑,是否有设计不合理。比如有个用户请求接口中,需要做业务操作、发站内通知和记录操作日志。为了实现起来比较方便,通常会将这些逻辑放在接口中同步执行,接口内部流程图如下:
这个接口表面上看起来没有问题,但如果你仔细梳理一下业务逻辑,会发现只有业务操作才是核心逻辑
,其他的功能都是非核心逻辑
。
在这里有个原则就是:核心逻辑可以同步执行,同步写库。非核心逻辑,可以异步执行,异步写库。
上面这个例子中,发站内通知和用户操作日志功能,对实时性要求不高,即使晚点写库,用户无非是晚点收到站内通知,或者运营晚点看到用户操作日志,对业务影响不大,所以完全可以异步处理。
通常异步主要有两种:多线程
和 mq
。
5.1 线程池
使用线程池
改造之后,接口逻辑如下:
发站内通知和用户操作日志功能,被提交到了两个单独的线程池中。
这样接口中重点关注的是业务操作,把其他的逻辑交给线程异步执行,这样改造之后,让接口性能瞬间提升了。
但使用线程池有个小问题就是:如果服务器重启了,或者是需要被执行的功能出现异常了,无法重试,会丢数据。
5.2 mq
使用mq
改造之后,接口逻辑如下:
对于发站内通知和用户操作日志功能,在接口中并没真正实现,它只发送了 mq 消息到 mq 服务器。然后由 mq 消费者消费消息时,才真正地执行这两个功能。
6. 避免大事务
在使用 spring 框架开发项目时使用@Transactional
注解提供事务功能,但也容易造成大事务,引发其他的问题。
看看大事务引发的问题:
大事务问题可能会造成接口超时,对接口的性能有直接的影响,遇到这类问题,往往这样优化:
-
少用 @Transactional 注解
-
将查询(select)方法放到事务外
-
事务中避免远程调用
-
事务中避免一次性处理太多数据
-
有些功能可以非事务执行
-
有些功能可以异步处理
7. 锁粒度
在某些业务场景中,多个线程并发修改某个共享数据,会造成数据异常。
为了解决并发场景下,多个线程同时修改数据造成数据不一致的情况,通常情况下,我们会:加锁
。
但如果锁加得不好,导致锁的粒度太粗,也会非常影响接口性能。
redis 分布式锁虽说好用,但它在使用时,有很多注意的细节,隐藏了很多坑,如果稍不注意很容易踩中。redis 分布式锁的 8 大坑具体如下:
mysql 数据库中主要有三种锁:
-
表锁:加锁快,不会出现死锁。但锁的粒度大,发生锁冲突的概率最高,并发度最低。
-
行锁:加锁慢,会出现死锁。但锁的粒度最小,发生锁冲突的概率最低,并发度也最高。
-
间隙锁:开销和加锁时间界于表锁和行锁之间。它会出现死锁,锁的粒度界于表锁和行锁之间,并发度一般。
并发度越高,意味着接口性能越好。
所以数据库锁的优化方向是:优先使用行锁
,其次使用间隙锁
,再其次使用表锁
。
8.分页处理
有时,我们会调用某个接口批量查询数据,这样一个场景:通过用户 id 批量查询出用户信息,然后给这些用户送积分。
但如果你一次性查询的用户数量太多了,比如一次查询 2000 个用户的数据。参数中传入了 2000 个用户的 id,远程调用接口,会发现该用户查询接口经常超时。
众所周知,调用接口从数据库获取数据,是需要经过网络传输的。如果数据量太大,无论是获取数据的速度,还是网络传输受限于带宽,都会导致消耗时间比较长。
那么,这种情况就需要分页处理
。
将一次获取所有数据的请求,改成分多次获取,每次只获取一部分用户的数据,最后进行合并和汇总。
其实,处理这个问题,要分为两种场景:同步调用
和 异步调用
。
9.加缓存
加缓存
是解决接口性能问题一个非常高效的方法。
但也需要视情况而定,加了缓存会导致接口的复杂度增加,它从而可能数据不一致。
在有些并发量比较低的场景中,比如用户下单,可以不用加缓存。
还有些场景,比如在商城首页显示商品分类的地方,假设这里的分类是调用接口获取到的数据,但页面暂时没有做静态化。
如果查询分类树的接口没有使用缓存,而直接从数据库查询数据,性能会非常差。
10. 分库分表
有时候,接口性能受限的不是别的,而是数据库。
当系统发展到一定的阶段,用户并发量大,会有大量的数据库请求,需要占用大量的数据库连接,同时会带来磁盘 IO 的性能瓶颈问题。
此外,随着用户数量越来越多,产生的数据也越来越多,一张表有可能存不下。由于数据量太大,sql 语句查询数据时,即使走了索引也会非常耗时。
这时就需要做分库分表
:
分库分表
主要有两个方向:垂直
和水平
,垂直方向(即业务方向)更简单。
在水平方向(即数据方向)上,分库和分表的作用,其实是有区别的,不能混为一谈。
-
分库
:为了解决数据库连接资源不足、磁盘 IO 的性能瓶颈问题。 -
分表
:为了解决单表数据量太大,SQL语句查询数据时即使走了索引也非常耗时问题。此外也会解决消耗CPU资源问题。 -
分库分表
:可解决数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时和消耗CPU资源等问题。
若用户并发量很大,但是需要保存的数据量很少,这时只分库、不分表;
若用户并发量不大,但是需要保存的数量很多,这时只分表、不分库;
若用户并发量大,并且需要保存的数量也很多时,可以分库分表。
11. 辅助功能
优化接口性能问题,除了上面提及到的常用方法,也需要配合使用一些辅助功能,如
11.1 开启慢查询日志
为了定位 sql 的性能瓶颈,开启 mysql 的慢查询日志就能把超过指定时间的 sql 语句,单独记录下来,方面以后分析和定位问题。
通过 mysql 的set
命令可以设置三个参数:
set global slow_query_log='ON'; //慢查询开关
set global slow_query_log_file='/usr/local/mysql/data/slow.log'; //慢查询日志存放的路径
set global long_query_time=2; //超过多少秒才会记录日志
如上设置,如果某条SQL执行时间超过了 2 秒,会被自动记录到 slow.log 文件中。
还有一种简单粗暴的方式,直接修改配置文件my.cnf
。
[mysqld]
slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 2
11.2 加监控
目前业界使用比较多的开源监控系统是:Prometheus
。可以用它监控如下信息:
-
接口响应时间
-
调用第三方服务耗时
-
慢查询 sql 耗时
-
cpu 使用情况
-
内存使用情况
-
磁盘使用情况
-
数据库使用情况
下面是配套资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
最后: 可以在公众号:程序员小濠 ! 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!