前言
每年金三银四&＃xff0c;金九银十之际&＃xff0c;想进阶梦想挑战大厂的朋友层出不穷。
梦想是要有的&＃xff0c;万一就实现了呢&＃xff1f;且撇开大牛们不说&＃xff0c;每年面试之时问题也层出不穷&＃xff0c;不得不说&＃xff0c;每年被算法绝杀的朋友也是不在少数啊。
这篇文的目的在于提醒朋友们不管你是正在进阶的小白还是经验丰富的大牛&＃xff0c;请熟练算法&＃xff0c;可能它就成为你成功进入大厂的阶梯呢&＃xff0c;最后祝正在准备进阶面试大厂的的朋友&＃xff0c;一切顺利&＃xff0c;如愿以偿。
第一次压测
惨不忍睹&＃xff0c;平均响应时间150ms&＃xff0c;而且在这次压测过程中还发现其它的问题&＃xff0c;后台报错&＃xff0c;经查是OpenSearch每秒查询次数限制
优化代码与配置
1、修改OpenSearch配置&＃xff0c;并且将压测环境中的OpenSearch连接地址改为内网地址。2、将代码中循环查询缓存的地方改为一次性批量查询返回。3、和相关同学确认后去掉项目中无用的代码。
第二次压测
虽然优化了代码&＃xff0c;修改了配置&＃xff0c;但是情况更糟糕了&＃xff0c;而且还改出了新的问题。当时&＃xff0c;反复检查了代码&＃xff0c;确定查询缓存的次数已经是最少了&＃xff0c;而且连接线程池相关参数也调到一个相对较大且合理的值了。如果&＃xff0c;再压测还是无法达到要求的话&＃xff0c;只有出最后一招了&＃xff1a;缓存结果集。即&＃xff0c;以用户ID和用户搜索的关键词为key&＃xff0c;查询的结果为value&＃xff0c;缓存5分钟。
第三次压测
总算符合要求了&＃xff0c;并发60的时候响应时间达到32ms&＃xff0c;而我又发现了新的优化点。
接口中居然还有查数据库的操作&＃xff0c;这可不能忍&＃xff0c;排查之后去掉了一些不必要的依赖。
成长
学会了使用RedisTemplate的executePipelined进行redis批量查询
针对本次优化的总结
1、一定要绝对避免循环查数据库和缓存&＃xff08;PS&＃xff1a;循环里面就不能有查询缓存&＃xff0c;更不能有查询数据库的操作&＃xff0c;因为循环的次数没法控制&＃xff09;&＃xff1b;
2、对于API接口的话&＃xff0c;一般都是直接查缓存的&＃xff0c;没有查数据库的&＃xff1b;
3、多用批量查询&＃xff0c;少用单条查询&＃xff0c;尽量一次查出来&＃xff1b;
4、对于使用阿里云&＃xff0c;要留意一下相应产品的配置&＃xff0c;该花的钱还是得花&＃xff0c;同时&＃xff0c;千万要记得正式环境中使用相应产品的内网地址&＃xff1b;
5、注意连接池大小&＃xff08;包括数据库连接池、Redis缓存连接池、线程池&＃xff09;&＃xff1b;
6、压测的机器上不要部署其它的服务&＃xff0c;只跑待压测的服务&＃xff0c;避免受其它项目影响&＃xff1b;对于线上环境&＃xff0c;最好一台机器上只部署一个重要的服务&＃xff1b;
7、没有用的以及被注释掉的代码&＃xff0c;没有用的依赖最好及时清理掉&＃xff1b;
8、集群自不用说&＃xff1b;
9、一些监控类的工具工具可以帮助我们更好的定位问题&＃xff0c;比如链路跟踪&＃xff0c;这次项目中使用了PinPoint&＃xff1b;
10、如果技术上优化的空间已经非常小了&＃xff0c;可以试着从业务上着手&＃xff0c;用实际的数据说话&＃xff0c;可以从日常的访问量&＃xff0c;历史访问量数据来说服测试&＃xff1b;
11、每一次代码改动都有可能引入新的问题&＃xff0c;因此&＃xff0c;每次修改代码后都要回归测试一下&＃xff08;PS&＃xff1a;每次修改完以后&＃xff0c;我都会用几组不同的关键词搜索&＃xff0c;然后比对修改前和修改后返回的数据是否一致&＃xff0c;这个时候postman&＃xff0c;以及Beyond compare就派上用场了&＃xff09;&＃xff1b;
12、关键的地方一定要多加点儿日志&＃xff0c;方便以后排除问题&＃xff0c;因为排查线上问题最主要还是靠日志&＃xff1b;
最后
由于篇幅限制&＃xff0c;小编在此截出几张知识讲解的图解&＃xff0c;有需要的程序猿&＃xff08;媛&＃xff09;可以点赞后戳这里免费领取全部资料获取哦
外链图片转存中…(img-0GbGNYbU-1619269620904)]
[外链图片转存中…(img-wsNNbIiN-1619269620905)]
京公网安备 11010802041100号