前言
国内项目普遍出现工期紧、工作量大、多人协作开发编码习惯不同,能力也参差不齐等多种因素,导致接口在上线后性能不满足预期。
本文从接口性能需求分析、接口性能准出标准、接口性能常见问题以及性能优化策略等多个方面,系统地完成接口性能优化的工作。
同时在项目交付过程中,可以通过 Code Review 、 技术债务等方式提前进行一部分接口性能的识别和优化,因为越复杂的项目拖到最后调整的代价越大。
接口性能需求分析流程
分析要点:
-
列举系统中核心场景,梳理出 API 接口清单,询问外部系统是否支持压测,防止将其它系统压崩
-
结合系统用户数、请求量、现有数据量以及未来几年的增长量,确定接口的性能指标,比如:TPS 等
-
准备预生产环境,进行 API 接口的压测
-
统计接口的 TPS、响应时间、CPU 占有率、内存占有率、接口错误率等数据指标
-
筛选不达标的接口,通过 APM 应用性能工具和调用链路查看耗时情况
-
根据具体情况进行 API 接口优化
接口性能的准出标准
以一个中等复杂软件系统为样例的接口性能准出标准:
接口性能优化方案
接口性能常见问题
代码结构不合理
-
循环调用数据库或者外部系统,导致耗时长
-
查询复杂单据详情时,不考虑实际情况,一股脑的把所有关联的数据查询出来
-
一次性加载巨量数据到内存中进行处理,耗时长或者 OOM 内存溢出
-
接口返回大量数据,接口处理时间长,网络传输时间长,前端页面处理数据时间长
-
执行数据库保存时,经常使用默认的 saveAll,导致一条条插入到数据,耗时长
-
大量非必要、不阻塞主流程的业务逻辑写在一起导致长事务、数据一致性等问题
-
不阻塞主流程或着可延迟处理的外部系统调用,都使用同步调用的方式
SQL 编写不合理
-
SQL 执行语句没有新建对应的索引
-
SQL 执行语句包含隐式类型转换、最左匹配失效、使用函数或表达式等导致慢 SQL
-
SQL join 了超过了三张及以上表
-
小表连大表,left join 无索引,导致全量扫描大表情况
-
深分页问题
-
order by 走文件排序
-
group by 使用了临时表
-
海量数据时count很慢,因 MySQL InnoDB count会遍历所有数据,计数准确但是性能较低
其他
-
请求高频、数据变更频率低,比如:基础数据、权限数据等,高并发下延迟大,可考虑使用缓存
-
MySQL 数据库并发顶不住的时候,比如:点赞等,可考虑使用 Redis 等先缓存扛着后同步到 MySQL
-
......
性能优化策略
1️⃣ 配置优化
-
JVM 参数
-
数据库连接池参数
-
硬件参数
2️⃣ 代码优化
-
减少外部资源重复调用
-
按需查询所关联的数据资源
-
批量操作数据库
3️⃣ 池化技术
-
使用线程池处理业务逻辑
-
使用对象池复用已有对象
-
HTTP 连接池访问外部系统
4️⃣ 数据库优化
-
使用索引 、 现有索引优化
-
SQL 编写不合理,避免太多表 Join、临时表、全表扫描
-
避免大事务,减少死锁
-
锁力度避免过粗,减少锁占用超时
-
深分页问题:1)通过ID记录标签 2)先深分页查询id,再inner join
5️⃣ 异步思想
-
耗时操作,考虑异步执行
-
同步远程调用由同步改为异步
-
非阻塞主流程业务改为异步
6️⃣ 缓存策略
-
Nginx 缓存
-
Redis 缓存 / 分布式缓存
-
本地缓存
-
注意数据一致性、缓存穿透、缓存击穿、大 Key 等问题
7️⃣ 大数据量处理
-
接口返回的数据量过大:分层分级返回、分批次返回、分页返回、压缩数据、延迟加载等
-
大量数据加载到内存,导致 OOM,可考虑分批次处理
-
海量数据时,count 查询慢,建议和分页列表接口分离
-
千万级别数据,可考虑冷热数据分离、数据库表分区、分库分表等
-
海量数据处理,考虑使用 NoSQL
8️⃣ 可观测性 & 工具
-
日志平台
-
分布式追踪
-
APM & 告警平台:CPU、内存监控
-
数据库:Explain语句(MySQL)
-
性能诊断工具:Jstack 查看进程信息
小结
API 接口优化是一个持续的过程,需要根据实际的业务需求和系统负载不断进行调整和优化。通过以上方法,可以显著提高API的性能、可用性和用户体验。
标签:缓存,数据,性能,接口,API,优化 From: https://blog.csdn.net/WBKJ_Noah_/article/details/141260063