一次生產事故的優化經歷

## 分析過程

跟蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或者資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍；下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫鏈結的相關錯誤了，但還是很多使用者反饋搶標時候打不開頁面。

在搶標過程中繼續觀察，apache的連線數在搶標的時候仍然可以飆到2600-2800之間，根據客服反饋，仍然有很多使用者反饋搶標的問題，但比之前稍微好一點，但是有零星的使用者反饋已經搶到標的，最後又給回退了。然後繼續觀察資料庫伺服器，使用top命令和mysqlworkbench檢視mysql主庫和從庫的各項負載嚇一跳（如下圖），mysql伺服器主庫的各項指標均已經達到峰值，而從庫幾乎沒有太大壓力。

跟蹤**發現，三端的業務**全部連線主庫，從庫只有後台的查詢業務在使用，於是立刻啟動改造；將除過搶標過程中的查詢外，其它頁面或者業務的所有查詢改造為查詢從庫，改造之後觀察，發現主庫的壓力明顯減少，從庫的壓力開始上來了。如下圖：

根據客服的反饋，改造之後搶到標回退的問題幾乎沒有了，搶標過程中頁面打不開或者開啟慢的問題有一定的緩解但仍有部分使用者反饋此問題，根據上面各專案分析結果得出：

當時根據這些情況寫了乙份優化的報告,見下文：

## 優化報告

1、web伺服器解決方案

單個使用者訪問web服務的示意圖

2、資料庫解決方案

當前資料庫的部署方案

2)增加快取伺服器。當從庫查詢到達峰值的時候，也會影響主從的同步，從而影響交易，因此對使用者經常使用的查詢進行快取以達到減少資料庫的請求壓力。需要新增三颱快取伺服器搭建redis集群。

3、其它優化

1）官網首頁靜態化，從cnzz統計來分析，首頁佔比**的整體訪問量的15%左右，對於首頁不經常變動的資料通過靜態化來處理，提公升官網開啟的流暢度。

2）apache伺服器的優化，開啟gzip壓縮，配置合理的鏈結數等

去掉投資過程中的更新熱點：標的進度表。每次投標成功或者失敗都需要對標的進度表進行更新，多執行緒更新的時候就會出現樂觀鎖等問題。去掉過程中的更新，只在滿標後將標的進度資訊儲存在標的進度表，優化投資過程中對資料庫的壓力。

2、增加快取減少資料的壓力，需要新增兩台大記憶體的快取伺服器

3、需要新增三颱web伺服器分解使用者訪問請求

官網需要新增一台伺服器

官網在搶標過程也有一定的壓力，需要新增一條伺服器，完成後示意圖如下：

總合計之後需要購置8臺伺服器，其中有兩台要求有大記憶體（64g以上）

備註：所有優化方案投產後，問題解決，搶標無憂！

出處：

一次生產事故的優化經歷

一次生產事故的優化經歷

一次生產事故的優化經歷

乙個電話避免了一次生產事故

相關推薦