前言
高并发十分考验架构师功底,它也是分布式架构设计中必须考虑的因素之一。要知道,光靠服务器堆是没有出路的。
想看看大牛是怎么面对高并发的?想知道BATJ大厂是怎么设计高可用架构的?这里有可参考的实践案例,干货满满,或许能对你有所启发。
Redis常用的数据类型
Redis的五种常用的数据类型分别是:String、Hash、List、Set和Sorted set
Redis的使用场景
1.Counting(计数)
2.展示最近、最热、点击率最高、活跃度最高等等条件的top list
3.用户最近访问记录也是redis list的很好应用场景
4.通过list的lpop及lpush接口进行队列的写入和消费
5.Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景,你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑
6.Redis提供的主从数据同步功能,其实是对cache的一个强有力功能扩展
第一次压测
惨不忍睹,平均响应时间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、关键的地方一定要多加点儿日志,方便以后排除问题,因为排查线上问题最主要还是靠日志;
《一线大厂Java面试真题解析+Java核心总结学习笔记+最新全套讲解视频+实战项目源码》开源
Java优秀开源项目:
-
ali1024.coding.net/public/P7/Java/git
- github.com/spring-projects
总结
虽然面试套路众多,但对于技术面试来说,主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同,没有规律可循。
上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料
有些面试官喜欢问自己擅长的问题,比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题,还有些面试官,尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的,然后通过提问的方式深挖细节,刨根到底。