一次生產事故的優化經歷

在一次正常的活動促銷以後，客服開始陸續反饋有用戶反應在搶標的時候打不開網頁或者APP，在打開的時候標的就已經被搶光了，剛開始沒有特別的上心，以爲搶標不就是這樣嗎，搶小米手機的時候也不就這樣嗎？隨着活動繼續推動，有更多的用戶強烈抗議，用戶領了加息卷或者抵現卷以後搶不上標的，認爲是平臺做假故意不讓使用以達到節省資源。

分析過程

其實之前也會有陸續的用戶反饋不減小，給客戶以小米搶手機爲例子忽悠了過去，此次用戶反饋太過強烈，才讓咱們重視了起來。咱們前端一共三款產品，app、官網、H5，其中app使用量最大，官網其次，H5平時使用量極少可是作活動期間流量會暴增（活動通常都是H5遊戲居多，H5也便於推廣營銷）,前端的三款產品都是分別使用lvs負載到後端的兩臺web服務器中（以下圖），此次用戶反饋基本在web和app端，因此重點觀察這四臺服務器。

首先懷疑網絡帶寬是否被涌滿，找到網絡工程師經過工具來監控，在搶標的時候帶寬最高使用率只有70%左右，隨排除之；再次懷疑web服務器是否抗不住了，使用top命令查看官網負載的兩臺服務器，在搶標的瞬間會飆到6-8左右，搶標後也慢慢的恢復了正常，app兩臺服務器高峯到10-12，隨後也恢復正常。

跟蹤web服務器業務日誌，發如今數據庫更新層報請求不到新的數據庫鏈接或者數據庫鏈接已經用完，認爲是數據庫的最大鏈接數過小，因而調整mysql數據庫最大鏈接數爲以往的3倍；下次搶標的時候繼續觀察業務日誌，發現已經不報數據庫連接的相關錯誤了，但仍是不少用戶反饋搶標時候打不開頁面。

繼續跟蹤web服務器，在搶標時使用命令（ps -ef|grep httpd|wc -l）查看httpd得鏈接數有1千左右，隨機查看apache配置文件中設置的最大鏈接數爲1024（apache默認的最大鏈接數爲256），原來搶標期間鏈接數已經到達最大鏈接數，不少用戶在搶標的過程當中已經獲取不到http鏈接致使頁面無響應或者app一直在等待中。因而調整apache配置文件中的最大鏈接數爲1024*3。

在搶標過程當中繼續觀察，apache的鏈接數在搶標的時候仍然能夠飆到2600-2800之間，根據客服反饋，仍然有不少用戶反饋搶標的問題，但比以前稍微好一點，可是有零星的用戶反饋已經搶到標的，最後又給回退了。而後繼續觀察數據庫服務器，使用top命令和MySQLWorkbench查看mysql主庫和從庫的各項負載嚇一跳（以下圖），mysql服務器主庫的各項指標均已經達到峯值，而從庫幾乎沒有太大壓力。

跟蹤代碼發現，三端的業務代碼所有鏈接主庫，從庫只有後臺的查詢業務在使用，因而馬上啓動改造；將除過搶標過程當中的查詢外，其它頁面或者業務的全部查詢改造爲查詢從庫，改造以後觀察，發現主庫的壓力明顯減小，從庫的壓力開始上來了。以下圖：

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

• 1 負載的兩臺服務器均已經達處處理的極限，須要配置更多的服務器來負載。
• 2 mysql主庫的壓力明顯減小，可是從庫的壓力卻上去了，須要將如今的一主一從已從改成一主多從的模式。
• 3 完全解決這些問題，須要綜合考慮平臺的總體優化，如：業務優化（去掉業務中熱點）、增長緩存、部分頁面靜態化（可使用雅虎和谷歌的前端優化規則，網上也有不少的測試網站能夠評測）等等。

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

優化報告

1 背景

隨着公司業務不斷髮展，業務量和用戶量的激增，官網pv也從最初的xxx-xxx到如今的xxx-xxxx，APP活躍用戶更是大幅增長；所以也對平臺目前的技術架構有了更大的挑戰。特別是近期平臺標源緊張的狀況下，滿標的時間更是愈來愈短。服務器的壓力也愈來愈大；所以須要升級目前的系統架構，以支持更大的用戶量和業務量。

2 用戶訪問示意圖

目前平臺有三款產品面對用戶，平臺官網、平臺APP、平臺小網頁；其中平臺官網和平臺APP的壓力比較大。

3 存在的問題

用戶搶標的時候問題集中在如下幾個方面
一、網頁或者APP打不開
二、網站或者APP打開慢
三、搶標過程當中轉帳成功後，由於服務器負責壓力大更新失敗，再次退款
四、數據庫鏈接數用完，致使滿標後添加投資記錄失敗，回退標的進度

四、分析

經過對近期的服務器參數，併發量，以及系統日誌等進行深刻的分析，得出：
一、平臺官網、平臺APP搶標過程當中服務器壓力巨大，其中平臺APP問題更加突出，搶標高峯期間單臺APP服務器apache最大鏈接數已經接近2600，接近apache最大的處理能力

二、數據庫服務器壓力巨大。數據庫壓力主要在兩個時期比較突出
1）當平臺作活動的時候，官網、小網頁、APP訪問量巨增，致使數據查詢量跟着巨增，當到達數據庫處理極限時，就會表現出網站打開慢等問題；
2）當用戶搶標的時候，用戶搶標的壓力又分爲兩個階段：搶標前和搶標中。搶標前，由於滿標速度很快，用戶提早打開搶標頁面不斷刷新，這樣數據庫的查詢壓力會不斷增大，若是搶標的用戶量很是大，會致使在搶標以前將數據庫鏈接數用完；搶標中，單次購買大概會涉及15張左右表進行更改查詢，每一個標的份額1000萬大概每次會有100-200人左右購買完成滿標，以中間值150人計算，在幾秒的時間內須要對數據更新2000-3000次(僅僅是更新，不包括查詢 )，產生大量併發，可能會致使更新失敗或者鏈接超時，從而影響到用戶投標和系統正常滿標。

5 解決方案

一、web服務器解決方案
單個用戶訪問web服務的示意圖

目前網站和平臺APP均是採用了兩臺服務來作均衡負責，每臺服務器中安裝了apache來作服務端接受處理，每臺apache最大能夠處理大約2000條鏈接。所以理論上目前網站或者APP能夠處理大於4000個用戶請求。若是要支持同時1萬的請求，則須要5臺apache服務器來支持,所以目前缺乏6臺web服務器。
升級服務器後的訪問示意圖

二、數據庫解決方案
當前數據庫的部署方案

1)主從分離解決主庫80%的查詢壓力。目前平臺官網、APP均鏈接mysql主庫致使主庫壓力倍增，把服務中的查詢所有遷移到從數據庫能夠大量減輕主庫的壓力。

2)增長緩存服務器。當從庫查詢到達峯值的時候，也會影響主從的同步，從而影響交易，所以對用戶常用的查詢進行緩存以達到減小數據庫的請求壓力。須要新增三臺緩存服務器搭建redis集羣。

三、其它優化
1）官網首頁靜態化，從cnzz統計來分析，首頁佔比網站的總體訪問量的15%左右，對於首頁不常常變更的數據經過靜態化來處理，提高官網打開的流暢度。

2）apache服務器的優化，開啓gzip壓縮，配置合理的連接數等

3) 去掉投資過程當中的更新熱點：標的進度表。每次投標成功或者失敗都須要對標的進度表進行更新，多線程更新的時候就會出現樂觀鎖等問題。去掉過程當中的更新，只在滿標後將標的進度信息保存在標的進度表，優化投資過程當中對數據庫的壓力。

6 服務器升級方案

一、平臺最大的壓力來自於數據庫，須要將如今的一主一從，改成一主四從。官網/app/小網頁產生的大量查詢，由虛IP分發到三臺從庫，後臺管理查詢走另外的一個從庫。數據庫須要新增三臺服務器
數據庫升級後的示意圖

二、增長緩存減小數據的壓力，須要新增兩臺大內存的緩存服務器

三、須要新增三臺web服務器分解用戶訪問請求

app須要新增兩臺服務器
在搶標過程當中app服務器壓力最大，須要新增兩臺服務器，配置完成後的示意圖

官網須要新增一臺服務器
官網在搶標過程也有必定的壓力，須要新增一條服務器，完成後示意圖以下：

總合計以後須要購置8臺服務器，其中有兩臺要求有大內存（64G以上）

公衆號回覆「優化」，可下載完整版word優化報告

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

---

做者：純潔的微笑
出處：http://www.ityouknow.com/
版權歸做者全部，轉載請註明出處