⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/cjsblog/p/10573215.html 「废物大师兄」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

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

业务逻辑

从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、关键的地方一定要多加点儿日志，方便以后排除问题，因为排查线上问题最主要还是靠日志