记一次优化天猫商城系统高并发的经验!
让一部分开发者看到未来
对于线上系统调优,它本身是个技术活,不仅需要很强的技术实战能力,很强的问题定位,问题识别,问题排查能力,还需要很丰富的调优能力。
(3)调用逻辑:下图为简要调用逻辑
二、何为单体架构项目
4.微服务:可理解为一个个小型的项目,如之前的ERP大型项目,划分为订单服务(订单项目),采购服务(采购项目),物料服务(物料项目)和销售服务(销售项目),以及服务之间调用
1.当秒杀的时候,cpu暴增
该系统每天秒杀分为三个时间端:10点,13点和20点,如下为秒杀的简要页面
图2
图3
2.单台运用服务器cpu
这个未保存截图,记得是600左右
connected_clients:600
四、排查过程及分析
根据服务部署和项目架构,从如下几个方面排查:
(1)应用服务器:排查内存,cpu,请求数等;
(2)文件图片服务器:排查内存,cpu,请求数等;
(3)计时器服务器:排查内存,cpu,请求数等;
(4)redis服务器:排查内存,cpu,连接数等;
(5)db服务器:排查内存,cpu,连接数等;
(二)排查过程
在秒杀后30分钟内,
2.redis请求超时
3.jdbc连接超时
4.通过gc查看,发现24小时内,FullGC发生了152次
(三)造成本次系统异常主要因素分析
五、最终解决方案
2.优化jvm参数,如下为本次优化后的参数
3.优化tomcat并发相关参数
主要是两方面:
(1)修改bio协议为nio2 (2)根据服务器配置,业务场景,业务流量等合理设置相关参数,尽量达到最优
关于tomcat相关参数优化,在接下来的文章中分析。
由于涉及到安全性问题,这里不列出
(1)优化掉大对象
(2)优化未及时释放的对象和连接资源
在conf/context.xml增大缓存
六、最终优化结果
经过几天观察,系统平稳
2.GC
cpu
七、总结
1.本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角度来与大家一起交流分享本次线上高并发调优整个闭环过程,当然,由于篇幅的限制,
有些细节和优化手段未在本篇文章中提及;
2.虽然解决了该问题,但是从长远来看,该单体项目仍然存在很大的问题和隐患,下面随便举几个:
(1)前后端紧耦合,未分离
(2)由于该系统秒杀业务属于非持续性并发,即局部性并发,当前并未做局部并发架构的调整
(3)由于该系统秒杀业务与该项目紧紧耦合在一起,未进行隔离,未独立成单独模块,未单独部署,从而存在因秒杀业务造成整个系统瘫痪的风险;
(4)未做流量削峰和流量限流,如加mq等软手段;
(5)redis为做高可用集群
作者:Alan_beijing
来源:https://urlify.cn/jyYny2
扫码加我微信进群,内推和技术交流,大佬们零距离