本文作者：狂乱的贵公子
原文地址：http://1t.click/kk5
最近做了一个搜索接口的优化，反复压测了四次，终于达到要求了，记录一下，晚上加个鸡腿????
从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、关键的地方一定要多加点儿日志，方便以后排除问题，因为排查线上问题最主要还是靠日志
●为了帮助前后端分离的新手，我做了一次大胆的尝试！
●公司倒闭 1 年了，而我当年的项目上了 GitHub 热榜
●Spring Boot 打包成的可执行 jar ，为什么不能被其他项目依赖？
●分布式数据库如何实现主键全局自增？
●Spring Boot 整合 Freemarker，50 多行配置是怎么省略掉的？
●@ResponseBody 总是乱码？这个问题得好好捋一捋！
●数据库分库分表，分片配置轻松入门！
●前后端分离时代，Java 程序员的变与不变！
●干货|最新版 Spring Boot2.1.5 教程+案例合集
●分布式数据库中间件 MyCat 搞起来！
本文分享自微信公众号 - 江南一点雨（a_javaboy）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
相关文章
