記一次線上商城系統高併發的優化

來源：https://urlify.cn/jyYny2

對於線上系統調優，它自己是個技術活，不只須要很強的技術實戰能力，很強的問題定位，問題識別，問題排查能力，還須要很豐富的調優能力。

本篇文章從實戰角度，從問題識別，問題定位，問題分析，提出解決方案，實施解決方案，監控調優後的解決方案和調優後的觀察等角度來與你們一塊兒交流分享本次線上高併發調優整個閉環過程。

1、項目簡要狀況概述

該項目爲基於SSM架構的商城類單體架構項目，其中有一個秒殺重磅模塊，以下爲當前線上環境的簡要架構部署圖，大體描述一下：

(1)項目爲SSM架構

(2)服務器類別：1臺負載均衡服務器(F5),3臺運用程序服務器，1臺計時器服務器,1臺redis服務器，1臺圖片服服務器和1臺基於Pass架構的Mysql主從服務器(微軟雲)

(3)調用邏輯：下圖爲簡要調用邏輯

2、何爲單體架構項目

從架構發展角度，軟件項目經歷了以下階段的發展：

1.單體架構：可理解爲傳統的先後端未分離的架構

2.垂直架構：可理解爲先後端分離架構

3.SOA架構：可理解爲按服務類別，業務流量，服務間依賴關係等服務化的架構，如之前的單體架構ERP項目，劃分爲訂單服務，採購服務，物料服務和銷售服務等

4.微服務：可理解爲一個個小型的項目，如以前的ERP大型項目，劃分爲訂單服務(訂單項目)，採購服務(採購項目)，物料服務(物料項目)和銷售服務(銷售項目)，以及服務之間調用

3、本SSM項目引起的線上問題

1.當秒殺的時候，cpu暴增

該系統天天秒殺分爲三個時間端：10點，13點和20點，以下爲秒殺的簡要頁面

圖1

圖2

圖3

2.單臺運用服務器cpu

3.單臺運用服務器請求數

4.rdis鏈接數（info clients）

這個未保存截圖，記得是600左右

connected_clients:600

5.mysql請求截圖

4、排查過程及分析

（一）排查思路

根據服務部署和項目架構，從以下幾個方面排查：

（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鏈接未及時釋放

5、最終解決方案

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"
/>

6、最終優化結果

通過幾天觀察，系統平穩

1.基本監控

2.GC

3.抽樣器cou和內存

cpu

內存

7、總結

1.本篇文章從實戰角度，從問題識別，問題定位，問題分析，提出解決方案，實施解決方案，監控調優後的解決方案和調優後的觀察等角度來與你們一塊兒交流分享本次線上高併發調優整個閉環過程，固然，因爲篇幅的限制，

有些細節和優化手段未在本篇文章中說起；

2.雖然解決了該問題，可是從長遠來看，該單體項目任然存在很大的問題和隱患，下面隨便舉幾個：

(1)先後端緊耦合，未分離

(2)因爲該系統秒殺業務屬於非持續性併發，即局部性併發，當前並未作局部併發架構的調整

(3)因爲該系統秒殺業務與該項目牢牢耦合在一塊兒，未進行隔離，未獨立成單獨模塊，未單獨部署，從而存在因秒殺業務形成整個系統癱瘓的風險；

(4)未作流量削峯和流量限流，如加mq等軟手段；

(5)redis爲作高可用集羣