對于線上系統(tǒng)調(diào)優(yōu)暮现，它本身是個技術(shù)活，不僅需要很強的技術(shù)實戰(zhàn)能力楚昭，很強的問題定位栖袋，問題識別，問題排查能力抚太，還需要很豐富的調(diào)優(yōu)能力塘幅。
? ? 本篇文章從實戰(zhàn)角度昔案，從問題識別，問題定位电媳，問題分析踏揣，提出解決方案，實施解決方案匾乓，監(jiān)控調(diào)優(yōu)后的解決方案和調(diào)優(yōu)后的觀察等角度來與大家一起交流分享本次線上高并發(fā)調(diào)優(yōu)整個閉環(huán)過程呼伸。
一? 項目簡要情況概述
? ? 該項目為基于SSM架構(gòu)的商城類單體架構(gòu)項目，其中有一個秒殺重磅模塊钝尸，如下為當前線上環(huán)境的簡要架構(gòu)部署圖括享，大致描述一下：
? ? (1)項目為SSM架構(gòu)
? ? (2)服務(wù)器類別：1臺負載均衡服務(wù)器(F5),3臺運用程序服務(wù)器，1臺計時器服務(wù)器,1臺redis服務(wù)器珍促，1臺圖片服服務(wù)器和1臺基于Pass架構(gòu)的Mysql主從服務(wù)器(微軟云)
? ? (3)調(diào)用邏輯：下圖為簡要調(diào)用邏輯
?二? 何為單體架構(gòu)項目
從架構(gòu)發(fā)展角度铃辖，軟件項目經(jīng)歷了如下階段的發(fā)展：
1.單體架構(gòu)：可理解為傳統(tǒng)的前后端未分離的架構(gòu)
2.垂直架構(gòu)：可理解為前后端分離架構(gòu)
3.SOA架構(gòu)：可理解為按服務(wù)類別，業(yè)務(wù)流量猪叙，服務(wù)間依賴關(guān)系等服務(wù)化的架構(gòu)娇斩，如以前的單體架構(gòu)ERP項目，劃分為訂單服務(wù)穴翩，采購服務(wù)犬第，物料服務(wù)和銷售服務(wù)等
4 微服務(wù)：可理解為一個個小型的項目，如之前的ERP大型項目芒帕，劃分為訂單服務(wù)(訂單項目)歉嗓，采購服務(wù)(采購項目)，物料服務(wù)(物料項目)和銷售服務(wù)(銷售項目)背蟆，以及服務(wù)之間調(diào)用
?三? 本SSM項目引發(fā)的線上問題
問題一：當秒殺的時候鉴分，cpu暴增。
該系統(tǒng)每天秒殺分為三個時間端：10點带膀，13點和20點志珍，如下為秒殺的簡要頁面
?圖1
圖2
?圖3
?2.單臺運用服務(wù)器cpu?
?3.單臺運用服務(wù)器請求數(shù)
?4.rdis連接數(shù)（info clients）
這個未保存截圖，記得是600左右
connected_clients:600?
5.mysql請求截圖
四? 排查過程及分析
（一）排查思路垛叨。
根據(jù)服務(wù)部署和項目架構(gòu)伦糯，從如下幾個方面排查：
（1）運用服務(wù)器：排查內(nèi)存，cpu,請求數(shù)等嗽元；
（2）文件圖片服務(wù)器：排查內(nèi)存敛纲，cpu,請求數(shù)等；
（3）計時器服務(wù)器：排查內(nèi)存还棱，cpu,請求數(shù)等载慈；
（4）redis服務(wù)器：排查內(nèi)存，cpu,連接數(shù)等珍手；
（5）db服務(wù)器：排查內(nèi)存办铡，cpu,連接數(shù)等得湘；
（二）排查過程
在秒殺后30分鐘內(nèi)尖阔，
1.運用程序服務(wù)器cpu暴增闯冷，內(nèi)存暴增铐维，造成cpu和內(nèi)存暴增的根本原因是請求數(shù)過高，單臺運用服務(wù)器達到3000多童叠；
2.redis請求超時
3.jdbc連接超時
?4.通過gc查看框喳，發(fā)現(xiàn)24小時內(nèi)，F(xiàn)ullGC發(fā)生了152次
?5.再看看堆棧厦坛，發(fā)現(xiàn)有一些線程阻塞和死鎖
jstat -l pid五垮，也可以通過VisualVM分析
?6.發(fā)現(xiàn)有2000多個線程請求無效資源
（三）造成本次系統(tǒng)異常主要因素分析
(1)在秒殺時，請求量過高杜秸，導(dǎo)致運用服務(wù)器負載過高放仗；
(2)redis連接池滿，獲取不到連接撬碟，connot get a connection from thread pool
(3)jdbc連接池滿诞挨，獲取不到連接和超時
(4)存在大對象代碼，如向list集合中不停添加對象呢蛤，不能及時回收對象導(dǎo)致內(nèi)存增加惶傻，頻繁發(fā)生Full GC
(5)tomcat并發(fā)參數(shù)，jvm優(yōu)化參數(shù)其障，jedis配置參數(shù)银室，jdbc配置參數(shù)不合理
(6)未對請求量進行削峰和限流
(7)資源連接未及時釋放，如redis連接静秆，jdbc連接未及時釋放
?五? 最終解決方案
1.增加運用服務(wù)粮揉，做流量削峰和分流
由于該項目未增加MQ，因此只能采用硬負載抚笔，增加服務(wù)器水平擴展方式來實現(xiàn)流量削峰和流量分流
?2.優(yōu)化jvm參數(shù)，如下為本次優(yōu)化后的參數(shù)
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"
關(guān)于這個jvm參數(shù)的優(yōu)化侨拦，jvm理論是怎樣的殊橙，官方建議是怎樣的，實戰(zhàn)是怎樣的狱从，將在下篇文章中分析膨蛮。
3.優(yōu)化tomcat并發(fā)相關(guān)參數(shù)
主要是兩方面：
(1)修改bio協(xié)議為nio2? (2)根據(jù)服務(wù)器配置，業(yè)務(wù)場景季研，業(yè)務(wù)流量等合理設(shè)置相關(guān)參數(shù)敞葛，盡量達到最優(yōu)
關(guān)于tomcat相關(guān)參數(shù)優(yōu)化，在接下來的文章中分析与涡。
4.redis 和jdbc參數(shù)優(yōu)化
由于涉及到安全性問題惹谐，這里不列出
5.代碼優(yōu)化
(1)優(yōu)化掉大對象
(2)優(yōu)化未及時釋放的對象和連接資源
6.解決000多個線程請求無效資源問題
在conf/context.xml增大緩存
<Resource?
? ? cachingAllowed = "true"
? ? cacheMaxSize = "102400"
/>
六 最終優(yōu)化結(jié)果
經(jīng)過幾天觀察持偏，系統(tǒng)平穩(wěn)
1.基本監(jiān)控
2.GC
3.抽樣器cou和內(nèi)存
cpu
?內(nèi)存
七? 總結(jié)
1.本篇文章從實戰(zhàn)角度，從問題識別氨肌，問題定位鸿秆，問題分析，提出解決方案怎囚，實施解決方案卿叽，監(jiān)控調(diào)優(yōu)后的解決方案和調(diào)優(yōu)后的觀察等角度來與大家一起交流分享本次線上高并發(fā)調(diào)優(yōu)整個閉環(huán)過程，當然恳守，由于篇幅的限制考婴，
有些細節(jié)和優(yōu)化手段未在本篇文章中提及；
2.雖然解決了該問題催烘，但是從長遠來看沥阱，該單體項目任然存在很大的問題和隱患，下面隨便舉幾個：
(1)前后端緊耦合颗圣，未分離
(2)由于該系統(tǒng)秒殺業(yè)務(wù)屬于非持續(xù)性并發(fā)喳钟，即局部性并發(fā)，當前并未做局部并發(fā)架構(gòu)的調(diào)整
(3)由于該系統(tǒng)秒殺業(yè)務(wù)與該項目緊緊耦合在一起在岂，未進行隔離奔则，未獨立成單獨模塊，未單獨部署蔽午，從而存在因秒殺業(yè)務(wù)造成整個系統(tǒng)癱瘓的風(fēng)險易茬；
(4)未做流量削峰和流量限流，如加mq等軟手段及老；
(5)redis未做高可用集群
自：https://www.cnblogs.com/wangjiming/p/13225544.html
