0%

实战-请讲下接口具体怎么优化

原文地址 https://mp.weixin.qq.com/s/Loun9b8A_zEsVcBJniww4Q

作者:狂乱的贵公子

最近做了一个搜索接口的优化,反复压测了四次,终于达到要求了,记录一下,晚上加个鸡腿🍗

业务逻辑

从 OpenSearch 中检索出数据,然后各种填充组装数据,最后返回

逻辑看似很简单,当初我也是这样认为的,于是预估 5 天完成,最后前前后后开发、联调、改 bug 直到上线差不多花了 10 天(当然这 10 天并不是只做这一件事情)

复杂在于影响返回结构的因素很多,排除问题需要检查配置、检查数据库、检查缓存、检查 OpenSearch、检查代码

言归正传,不管逻辑有多复杂,都不是你逃避问题的接口,更不是你不去优化的理由,这不是本文的重点,优化过程才是

要求,给 APP 提供的接口一般要求响应时间在 100ms 以内

第一次压测

惨不忍睹,平均响应时间 150ms,而且在这次压测过程中还发现其它的问题,后台报错,经查是 OpenSearch 每秒查询次数限制

优化代码与配置

1、修改 OpenSearch 配置,并且将压测环境中的 OpenSearch 连接地址改为内网地址

2、将代码中循环查询缓存的地方改为一次性批量查询返回

3、和相关同学确认后去掉项目中无用的代码

第二次压测

虽然优化了代码,修改了配置,但是情况更糟糕了,而且还改出了新的问题

当时,反复检查了代码,确定查询缓存的次数已经是最少了,而且连接线程池相关参数也调到一个相对较大且合理的值了

如果,再压测还是无法达到要求的话,只有出最后一招了:缓存结果集

即,以用户 ID 和用户搜索的关键词为 key,查询的结果为 value,缓存 5 分钟

第三次压测

总算符合要求了,并发 60 的时候响应时间达到 32ms,而我又发现了新的优化点

接口中居然还有查数据库的操作,这可不能忍,排查之后去掉了一些不必要的依赖

成长

学会了使用 RedisTemplate 的 executePipelined 进行 redis 批量查询

针对本次优化的总结

1、一定要绝对避免循环查数据库和缓存(PS:循环里面就不能有查询缓存,更不能有查询数据库的操作,因为循环的次数没法控制)

2、对于 API 接口的话,一般都是直接查缓存的,没有查数据库的

3、多用批量查询,少用单条查询,尽量一次查出来

4、对于使用阿里云,要留意一下相应产品的配置,该花的钱还是得花,同时,千万要记得正式环境中使用相应产品的内网地址

5、注意连接池大小(包括数据库连接池、Redis 缓存连接池、线程池)

6、压测的机器上不要部署其它的服务,只跑待压测的服务,避免受其它项目影响;对于线上环境,最好一台机器上只部署一个重要的服务

7、没有用的以及被注释掉的代码,没有用的依赖最好及时清理掉

8、集群自不用说

9、一些监控类的工具工具可以帮助我们更好的定位问题,比如链路跟踪,这次项目中使用了 PinPoint

10、如果技术上优化的空间已经非常小了,可以试着从业务上着手,用实际的数据说话,可以从日常的访问量,历史访问量数据来说服测试

11、每一次代码改动都有可能引入新的问题,因此,每次修改代码后都要回归测试一下(PS:每次修改完以后,我都会用几组不同的关键词搜索,然后比对修改前和修改后返回的数据是否一致,这个时候 postman,以及 Beyond compare 就派上用场了)

12、关键的地方一定要多加点儿日志,方便以后排除问题,因为排查线上问题最主要还是靠日志

原文链接:

www.cnblogs.com/cjsblog/p/10573215.html

程序汪往期精彩文章包含答案

程序汪最近整理的 BAT 大小厂面试题 2019 (面试题目录推荐)

目录:我把精华文章都整理出来了

程序员新人刚进公司很懵逼,程序汪给 5 个建议

19 个强大、有趣、好玩、又装 B 的 Linux 命令!

Tomcat 爆出高危漏洞!

程序汪推荐你去阿里巴巴 java 后端岗位,进来看看

阎王爷让我给他做个生死簿后台管理系统

疫情当下, 帮公司远程技术电话面试 java 期望 1 万 7 千程序员

继续帮公司面试 2 万的 java 程序员,一轮电话面试很基础

这是目前最快的 Java 框架,300 个框架中排名第一,真香

1
给个[在看],是对程序汪最大的支持
-------------本文结束感谢您的阅读-------------
请我吃辣条吧~~ 谢谢打赏!