牛掰！一次線上商城系統高并發優化實戰！
對于線上系統調優，它本身是個技術活，不僅需要很強的技術實戰能力，很強的問題定位，問題識別，問題排查能力，還需要很豐富的調優能力。
圖片來自 Pexels
本篇文章站在實戰角度，從問題識別，問題定位，問題分析，提出解決方案，實施解決方案，監控調優后的解決方案和調優后的觀察等角度來與大家交流分享線上高并發調優整個閉環過程。
項目簡要情況概述
該項目為基于 SSM 架構的商城類單體架構項目，其中有一個秒殺重磅模塊，如下為當前線上環境的簡要架構部署圖。
大致描述一下：
- 項目為 SSM 架構。
- 服務器類別：1 臺負載均衡服務器(F5)，3 臺運用程序服務器，1 臺計時器服務器，1 臺 Redis 服務器，1 臺圖片服服務器和 1 臺基于 Pass 架構的 MySQL 主從服務器(微軟云)。
- 調用邏輯：上圖為簡要調用邏輯。
何為單體架構項目
從架構發展角度，軟件項目經歷了如下階段的發展：
- 單體架構：可理解為傳統的前后端未分離的架構。
- 垂直架構：可理解為前后端分離架構。
- SOA 架構：可理解為按服務類別，業務流量，服務間依賴關系等服務化的架構，如以前的單體架構 ERP 項目，劃分為訂單服務，采購服務，物料服務和銷售服務等。
- 微服務：可理解為一個個小型的項目，如之前的 ERP 大型項目，劃分為訂單服務(訂單項目)，采購服務(采購項目)，物料服務(物料項目)和銷售服務(銷售項目)，以及服務之間調用。
本 SSM 項目引發的線上問題
①當秒殺的時候，CPU 暴增
該系統每天秒殺分為三個時間端：10 點，13 點和 20 點，如下為秒殺的簡要頁面：
②單臺運用服務器 CPU
③單臺運用服務器請求數
④rdis 連接數(info clients)
這個未保存截圖，記得是 600 左右：
- connected_clients:600
⑤MySQL 請求截圖
排查過程及分析
排查思路
根據服務部署和項目架構，從如下幾個方面排查：
- 運用服務器：排查內存，CPU，請求數等。
- 文件圖片服務器：排查內存，CPU，請求數等。
- 計時器服務器：排查內存，CPU，請求數等。
- Redis 服務器：排查內存，CPU，連接數等。
- DB 服務器：排查內存，CPU，連接數等。
排查過程
在秒殺后 30 分鐘內：
①運用程序服務器 CPU 暴增，內存暴增，造成 CPU 和內存暴增的根本原因是請求數過高，單臺運用服務器達到 3000 多。
②Redis 請求超時，如下圖：
③JDBC 連接超時，如下圖：
④通過 GC 查看，發現 24 小時內，FullGC 發生了 152 次，如下圖：
⑤再看看堆棧，發現有一些線程阻塞和死鎖。
jstat -l pid，也可以通過 VisualVM 分析：
⑥發現有 2000 多個線程請求無效資源，如下圖：
造成本次系統異常主要因素分析
造成本次系統異常主要因素分析如下：
- 在秒殺時，請求量過高，導致運用服務器負載過高。
- Redis 連接池滿，獲取不到連接，connot get a connection from thread pool。
- JDBC 連接池滿，獲取不到連接和超時。
- 存在大對象代碼，如向 List 集合中不停添加對象，不能及時回收對象導致內存增加，頻繁發生 Full GC。
- Tomcat 并發參數，JVM 優化參數，Jedis 配置參數，JDBC 配置參數不合理。
- 未對請求量進行削峰和限流。
- 資源連接未及時釋放，如 Redis 連接，JDBC 連接未及時釋放。
最終解決方案
①增加運用服務，做流量削峰和分流
由于該項目未增加 MQ，因此只能采用硬負載，增加服務器水平擴展方式來實現流量削峰和流量分流：
②優化 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 理論是怎樣的，官方建議是怎樣的，實戰是怎樣的，將在下篇文章中分析。
③優化 Tomcat 并發相關參數
主要是兩方面：
- 修改 bio 協議為 nio2 。
- 根據服務器配置，業務場景，業務流量等合理設置相關參數，盡量達到最優。
關于 Tomcat 相關參數優化，在接下來的文章中分析。
④Redis 和 JDBC 參數優化
由于涉及到安全性問題，這里不列出。
⑤代碼優化
代碼優化如下：
- 優化掉大對象。
- 優化未及時釋放的對象和連接資源。
⑥解決 000 多個線程請求無效資源問題：
- 在conf/context.xml增大緩存
- <Resource
- cachingAllowed = "true"
- cacheMaxSize = "102400"
- />
最終優化結果
經過幾天觀察，系統平穩。
基本監控，如下圖：
GC，如下圖：
抽樣器 CPU 和內存：
總結
由于篇幅的限制有些細節和優化手段未在本篇文章中提及。雖然解決了該問題，但是從長遠來看，該單體項目任然存在很大的問題和隱患。
下面隨便舉幾個：
前后端緊耦合，未分離。
- 由于該系統秒殺業務屬于非持續性并發，即局部性并發，當前并未做局部并發架構的調整。
- 由于該系統秒殺業務與該項目緊緊耦合在一起，未進行隔離，未獨立成單獨模塊，未單獨部署，從而存在因秒殺業務造成整個系統癱瘓的風險。
- 未做流量削峰和流量限流，如加 MQ 等軟手段。
- Redis 為做高可用集群。
作者：Alan_beijing
編輯：陶家龍
出處：http://www.cnblogs.com/wangjiming/
