起源：https://urlify.cn/jyYny2
对于线上零碎调优，它自身是个技术活，不仅须要很强的技术实战能力，很强的问题定位，问题辨认，问题排查能力，还须要很丰盛的调优能力。
本篇文章从实战角度，从问题辨认，问题定位，问题剖析，提出解决方案，施行解决方案，监控调优后的解决方案和调优后的察看等角度来与大家一起交换分享本次线上高并发调优整个闭环过程。
一、我的项目简要状况概述
该我的项目为基于 SSM 架构的商城类单体架构我的项目，其中有一个秒杀重磅模块，如下为当火线上环境的简要架构部署图，大抵形容一下：
(1)我的项目为 SSM 架构
(2)服务器类别：1 台负载平衡服务器(F5),3 台使用程序服务器，1 台计时器服务器,1 台 redis 服务器，1 台图片服服务器和 1 台基于 Pass 架构的 Mysql 主从服务器(微软云)
(3)调用逻辑：下图为简要调用逻辑
二、何为单体架构我的项目
从架构倒退角度，软件我的项目经验了如下阶段的倒退：
1. 单体架构：可了解为传统的前后端未分离的架构
2. 垂直架构：可了解为前后端拆散架构
3.SOA 架构：可了解为按服务类别，业务流量，服务间依赖关系等服务化的架构，如以前的单体架构 ERP 我的项目，划分为订单服务，洽购服务，物料服务和销售服务等
4. 微服务：可了解为一个个小型的我的项目，如之前的 ERP 大型项目，划分为订单服务 (订单我的项目)，洽购服务(洽购我的项目)，物料服务(物料我的项目) 和销售服务(销售我的项目)，以及服务之间调用
三、本 SSM 我的项目引发的线上问题
1. 当秒杀的时候，cpu 暴增
该零碎每天秒杀分为三个工夫端：10 点，13 点和 20 点，如下为秒杀的简要页面
图 1
图 2
图 3
2. 单台使用服务器 cpu
3. 单台使用服务器申请数
4.rdis 连接数（info clients）
这个未保留截图，记得是 600 左右
connected_clients:600
5.mysql 申请截图
四、排查过程及剖析
（一）排查思路
依据服务部署和我的项目架构，从如下几个方面排查：
（1）使用服务器：排查内存，cpu, 申请数等；
（2）文件图片服务器：排查内存，cpu, 申请数等；
（3）计时器服务器：排查内存，cpu, 申请数等；
（4）redis 服务器：排查内存，cpu, 连接数等；
（5）db 服务器：排查内存，cpu, 连接数等；
（二）排查过程
在秒杀后 30 分钟内，
1. 使用程序服务器 cpu 暴增，内存暴增，造成 cpu 和内存暴增的根本原因是申请数过高，单台使用服务器达到 3000 多；
2.redis 申请超时
3.jdbc 连贯超时
4. 通过 gc 查看，发现 24 小时内，FullGC 产生了 152 次
5. 再看看堆栈，发现有一些线程阻塞和死锁
jstat -l pid，也能够通过 VisualVM 剖析
6. 发现有 2000 多个线程申请有效资源
（三）造成本次零碎异样次要因素剖析
(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 连贯未及时开释
五、最终解决方案
1. 减少使用服务，做流量削峰和分流
因为该我的项目未减少 MQ，因而只能采纳硬负载，减少服务器程度扩大形式来实现流量削峰和流量分流
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)依据服务器配置，业务场景，业务流量等正当设置相干参数，尽量达到最优
对于 tomcat 相干参数优化，在接下来的文章中剖析。
4.redis 和 jdbc 参数优化
因为波及到安全性问题，这里不列出
5. 代码优化
(1)优化掉大对象
(2)优化未及时开释的对象和连贯资源
6. 解决 000 多个线程申请有效资源问题
在 conf/context.xml 增大缓存
<Resource
cachingAllowed = "true"
cacheMaxSize = "102400"
/>六、最终优化后果
通过几天察看，零碎安稳
1. 根本监控
2.GC
3. 抽样器 cou 和内存
cpu
内存
七、总结
1. 本篇文章从实战角度，从问题辨认，问题定位，问题剖析，提出解决方案，施行解决方案，监控调优后的解决方案和调优后的察看等角度来与大家一起交换分享本次线上高并发调优整个闭环过程，当然，因为篇幅的限度，
有些细节和优化伎俩未在本篇文章中提及；
2. 尽管解决了该问题，然而从久远来看，该单体我的项目任然存在很大的问题和隐患，上面轻易举几个：
(1)前后端紧耦合，未分离
(2)因为该零碎秒杀业务属于非持续性并发，即局部性并发，以后并未做部分并发架构的调整
(3)因为该零碎秒杀业务与该我的项目紧紧耦合在一起，未进行隔离，未独立成独自模块，未独自部署，从而存在因秒杀业务造成整个零碎瘫痪的危险；
(4)未做流量削峰和流量限流，如加 mq 等软伎俩；
(5)redis 为做高可用集群