同事线上埋的这个坑,我整整找了3天3夜

云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

对于线上系统调优,它本身是个技术活,不仅需要很强的技术实战能力,很强的] u 7 ( Z v * S问题定位,问题识别,问题排查能力,还需要很丰富的调优能力。

本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案i g T 4 V E实施解决方案m z z b监控调优后的解决方案和调优后的观察等角度来与大家一起交流分享本次线上高并发调优整个闭环过程。

一、项目简要情v Y D Y { 9 z况概述

该项目为基于SSM架构的商城类单体架构项目,其中有一个秒杀重磅模块,如下为当前线s 4 ) 3 @ X上环境的简要架构部署图d i t,大致描述一下:
(1)项目为SSM架构
(2)服务器类别:1台负载均G Q .服务器(F5),3台运用Q E ] r 8 z 3 {程序服务器,1台计时器服务器,1台redis服务器,1台图片服服务器和1台基于Pass架构的Mysql主从服务器(微软云)
(3)调用逻辑:下图为简要调用逻辑

同事线上埋的这个坑,我整整找了3天3夜

二、何为单体架构项目

从架构发展角度,软件项目经历了如下阶段的发展:
1.单体架构:可理解为传统x y ~ `的前后端未分离的架构
2.垂直架构:可理解为前后端分离架构
3.SOA架构:_ B g I 6 ) 5 O可理解为按服务类别,业务流量,服务间依赖关系等服务化的架构,如以前的单体架构ERP项目,划分为订单服务,采购服务,M X o * & }物料服务和销售服务等
4.微服务:可理解为一个个小型的项目,如之前的ERP大型项目,划分为订单服务(订单项目),采购服务(采购项目),物料服务(物料项目)和销售服务(销售项目),以及服务之间调用

同事线上埋的这个坑,我整整找了3天3夜

三、本SSM项目引发的线上问题

1.当秒杀的时候,cpu暴增
该系统每天秒杀分为三个时间端:10点,13点和20点,如下为秒杀的简要页面

同事线上埋的这个坑,我整整找了3天3夜
同事线上埋的这个坑,我整整找了3天3夜

2.单台运用服务器cpu

同事线上埋的这个坑,我整整找了3天3夜

3.单台运用服务器请求数

同事线上埋的这个坑,我整整找了3天3夜

4.rdis连] 6 ` 7 0接数(info clients)

这个未保存截图,记得是600左右
connected_clients:600

5.mysql请求截图& 8 n a w 0 ,

同事线上埋的这个坑,我整整找了3天3夜

四、排查过T d A y 3 ~ c | C程及分析

(一)排查思路
根据服务部署和项目架构,从如下几个方面排查:
(1)运用服务器:排查内存,cpu,请求数等;
(2)文件图片服务器:排查内存,cpu,请求数等;
(3)计时器服务器:排查内存,cpu,请求数等;
(4)redis服务器:排查内存C ` ] T X n B 6,cpu,连接数等;
(5)db服务器:排查内存,cpa 3 ( 9 ` G Zu,连接数等;

(二)排查过程
在秒杀后30分钟内,
1.运用程序服= c P - g务器cpu暴增,内存暴增,造成cpu和内存暴增的根本原因: = P 0 z H是请求数过高,单台运用服务器达到3000多;

同事线上埋的这个坑,我整整找了3天3夜

同事线上埋的这个坑,我整整找了3天3夜

(三)造成本次系统异常主要因素分析

(1)在秒杀时,请求量过高,导致运用n [ . I B s j服务器负载过高;
(2)redis连接池满,获取不到9 ( Y s D u E t U连接,connot get a connection from thread pool
(3)jdbc连接池满,获取不到连接和超时
(4)存在大对8 [ ] ( 4 G l象代码,如向list集合中不停添加对象,不能及时回收对象导致内存增加,频D M W @繁发生Full GC
(5)tomcat并发参数,jvm优化参数,jedis配置参数- % n ! = ` T,jdbc配置参数不合理
(6)未对请求量进行削5 U G % & F峰和限流
(7)资源连接` U ) f未及时释放,如redis连接,jdbc连接未及时释放

五、最. D K , p 8终解决方案

1.增加运用服务,做流量削峰和分流
由于该项目未增加MQ,因此只能采用T ? : l A 6 K 5 O硬负载,增加服务器水平扩展方式来实现流量削峰和流量分流

同事线上埋的这个坑,我整整找了3天3夜

2.优化jvm参数,如下为本次优化后的参数
JAVA_OPTS="-sec o L n } r Vrver -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMe2 x } I X Jthods -XX:+UseCMSInitiatingOccupancyOnly -Y B 7 kXX:CMSInitiatingOccupancyFraction=70 -DV Q l 6file.encoding=UTF8 -Duser.timezone=GMT+08"
关于这个jvm参数的优化,jvm理论是怎样的,官方建议是怎样的,实战是怎样的,将在下篇文章中分析。

3.优化tomcat并q d n Z n n T i发相关参数
主要是两方面:
(1)修改bio协议为nio2 (2)根据服务器配置,业务场景,业务流量等合理设置相关参{ x . b ? F Q L数,尽量达到最优

同事线上埋的这个坑,我整整找了3天3夜

关于tomcat相关参数优化,在接下来的文章中分析B B 9 +

4.redis 和jdbc参7 r _ * 9 k # 9 ^数优化
由于涉及到安全性问题,这里不列出

5.代码优化
(1)优化掉大对t ] m W ? D q
(2)优化未及时释放的对象和连接资源
6.解决000多个线程请求无效资源问题
在conf/context.xml增大缓存

caY 5 ) K i nchiL c  B ngAllowed = "true"
cacheA # %MaxSize = "102400"

/>

六、最终$ l k R Z m优化结果

经过几天观察,系统平稳
1.基本监控

同事线上埋的这个坑,我整整找了3天3夜
同事线上埋的这个坑,我整整找了3天3夜

七、总结

1.本篇文章从实战角度,从问题识8 g e S + f Y X别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角? z Y h度来与大家一起交流分享本次线上高并发调优整个闭环过程,当然,由于篇幅的限制,
有些细节和优化手段未在本篇文章中提及;

2.虽然解决了该问题,但是从长远来看,该单体项目任然存在很大的问题和隐患,下面随便举几个:
(1)前后端紧耦合,未分离
(2)由于该系统秒杀业务属于非持续性并发,即局部性并发,当前并未做M d J局部并发架构的调整
(3)由于该系统秒杀业务与该项目紧紧耦合在一起,未进行隔离,未独立成单独模块,未单独部署,从而存在因秒杀业务造成整个系统瘫痪的风险;
(4)未做流量削峰和流量限流,如加mq等软手) e 8 h ] 6 u c y段;
(5)rg 0 H s )edis为做高可用集群

【云栖号在线课堂】每天都有m h C * - ; w V I产品技术4 % u ( ? p g D I专家分享!
课程地址:https://yq$ F K + / Y Qh.alP 9 n uiyun.com/zhibo

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https:/# T 2 z ) x/c.tb.cnu $ L ~ . W/F6 C p ] /3.Z8gvnK

原文发布时间:2020-07-31
本文作者:Alan_beijing
本文来自:“互联网架构师”,了解相关信息可以关注“互联网架构师”