记一次线上商城系统高并发的优化

对于线上系统调优,它自己是个技术活,不只须要很强的技术实战能力,很强的问题定位,问题识别,问题排查能力,还须要很丰富的调优能力。mysql

本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角度来与你们一块儿交流分享本次线上高并发调优整个闭环过程。程序员

1、项目简要状况概述

该项目为基于SSM架构的商城类单体架构项目,其中有一个秒杀重磅模块,以下为当前线上环境的简要架构部署图,大体描述一下:面试

(1)项目为SSM架构redis

(2)服务器类别:1台负载均衡服务器(F5),3台运用程序服务器,1台计时器服务器,1台redis服务器,1台图片服服务器和1台基于Pass架构的Mysql主从服务器(微软云)sql

(3)调用逻辑:下图为简要调用逻辑后端

5f79c853e8984feb94529ff740ba0644


2、何为单体架构项目

从架构发展角度,软件项目经历了以下阶段的发展:缓存

1.单体架构:可理解为传统的先后端未分离的架构tomcat

2.垂直架构:可理解为先后端分离架构安全

3.SOA架构:可理解为按服务类别,业务流量,服务间依赖关系等服务化的架构,如之前的单体架构ERP项目,划分为订单服务,采购服务,物料服务和销售服务等服务器

4.微服务:可理解为一个个小型的项目,如以前的ERP大型项目,划分为订单服务(订单项目),采购服务(采购项目),物料服务(物料项目)和销售服务(销售项目),以及服务之间调用

884ea43c1d0a41bdaa16bfb44a5b1ef1


3、本SSM项目引起的线上问题

1.当秒杀的时候,cpu暴增

该系统天天秒杀分为三个时间段:10点,13点和20点,以下为秒杀的简要页面

图1

dd1cb264721e44cfbee2dbb74ea3fc9a

图2

eb36c3acf38148f3b2f4e428987c5509

 图3

488dfa9ec8eb41a995b75a6fa70c86bc

2.单台运用服务器cpu 

6d8a7bc0b32c4087936dcf089a5cbcc7

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

6900a02b4e154b38a8125209e9de65f1

4.rdis链接数(info clients)

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

connected_clients:600 

5.mysql请求截图

5bbb00f0a279464c8480e4e8d90eb4ca


4、排查过程及分析

(一)排查思路

根据服务部署和项目架构,从以下几个方面排查:

(1)运用服务器:排查内存,cpu,请求数等;

(2)文件图片服务器:排查内存,cpu,请求数等;

(3)计时器服务器:排查内存,cpu,请求数等;

(4)redis服务器:排查内存,cpu,链接数等;

(5)db服务器:排查内存,cpu,链接数等;

(二)排查过程

在秒杀后30分钟内,

1.运用程序服务器cpu暴增,内存暴增,形成cpu和内存暴增的根本缘由是请求数太高,单台运用服务器达到3000多;

6900a02b4e154b38a8125209e9de65f1

2.redis请求超时

2abd86d38689478b8a8c5430b5678c3f

3.jdbc链接超时

d1ea31fb81fa48bc92768f6a15ff42d4

4.经过gc查看,发现24小时内,FullGC发生了152次

b5dafa4ee2ac4eabb56bd74f17ee9784

5.再看看堆栈,发现有一些线程阻塞和死锁

jstat -l pid,也能够经过VisualVM分析

5539f68a079f4563ada44fb19cf2f131

6.发现有2000多个线程请求无效资源

0c5dc42238964d95bc7fc5bb07096882

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

(1)在秒杀时,请求量太高,致使运用服务器负载太高;

(2)redis链接池满,获取不到链接,connot get a connection from thread pool

(3)jdbc链接池满,获取不到链接和超时

(4)存在大对象代码,如向list集合中不停添加对象,不能及时回收对象致使内存增长,频繁发生Full GC

(5)tomcat并发参数,jvm优化参数,jedis配置参数,jdbc配置参数不合理

(6)未对请求量进行削峰和限流

(7)资源链接未及时释放,如redis链接,jdbc链接未及时释放


5、最终解决方案

1.增长运用服务,作流量削峰和分流

因为该项目未增长MQ,所以只能采用硬负载,增长服务器水平扩展方式来实现流量削峰和流量分流

6a7f276adec14ba6b10a0f8ac6e26652

2.优化jvm参数,以下为本次优化后的参数

JAVA_OPTS="-server -Xmx9g -Xms9g -Xmn3g -Xss500k -XX:+DisableExplicitGC -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -Dfile.encoding=UTF8 -Duser.timezone=GMT+08"

关于这个jvm参数的优化,jvm理论是怎样的,官方建议是怎样的,实战是怎样的,将在下篇文章中分析。

3.优化tomcat并发相关参数

主要是两方面:

(1)修改bio协议为nio2  (2)根据服务器配置,业务场景,业务流量等合理设置相关参数,尽可能达到最优

b599a2080c734f2e811e7667cc2004a3

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

4.redis 和jdbc参数优化

因为涉及到安全性问题,这里不列出

5.代码优化

(1)优化掉大对象

(2)优化未及时释放的对象和链接资源

6.解决000多个线程请求无效资源问题

在conf/context.xml增大缓存

<Resource 

    cachingAllowed = "true"

    cacheMaxSize = "102400"

/>

6、最终优化结果

通过几天观察,系统平稳

1.基本监控

9dc1a582b0c448fa8f0ab76c2d7e9a29

2.GC

8efd85a53c564ed2bfa431fd2754a70a

3.抽样器cou和内存

cpu

00032acdbd134f64aca27f22a3acdb31

内存

a765f64062954f8c9579e8dbaa0f49a8


7、总结

1.本篇文章从实战角度,从问题识别,问题定位,问题分析,提出解决方案,实施解决方案,监控调优后的解决方案和调优后的观察等角度来与你们一块儿交流分享本次线上高并发调优整个闭环过程,固然,因为篇幅的限制,

有些细节和优化手段未在本篇文章中说起;

2.虽然解决了该问题,可是从长远来看,该单体项目仍然存在很大的问题和隐患,下面随便举几个:

(1)先后端紧耦合,未分离

(2)因为该系统秒杀业务属于非持续性并发,即局部性并发,当前并未作局部并发架构的调整

(3)因为该系统秒杀业务与该项目牢牢耦合在一块儿,未进行隔离,未独立成单独模块,未单独部署,从而存在因秒杀业务形成整个系统瘫痪的风险;

(4)未作流量削峰和流量限流,如加mq等软手段;

(5)redis为最高可用集群


推荐阅读:

牛皮了,马士兵老师全网首播阿里P8级技术、实现大型淘宝实战落

面试美团被JVM惨虐?阿里P9架构师用500分钟把JVM从入门讲到实战#合集

清华启蒙架构师马士兵针对应届生到开发十年的Java程序员作职业把脉

马士兵教育:Spring源码实战全集,资深架构师带你搞懂Spring源码底层从入门到入坟

阿里P9架构师120分钟带你掌握线程池,不在为线程而烦恼

相关文章
相关标签/搜索