在一次正常的活動促銷之后，客服開始陸續反饋有用戶反應在搶標的時候打不開網頁或者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 背景

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

2 用戶訪問示意圖

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

3 存在的問題

用戶搶標的時候問題集中在以下幾個方面1、網頁或者APP打不開2、網站或者APP打開慢3、搶標過程中轉賬成功后，因為服務器負責壓力大更新失敗，再次退款4、數據庫連接數用完，導致滿標后添加投資記錄失敗，回退標的進度

4、分析

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

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

5 解決方案

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

目前網站和平臺APP均是采用了兩臺服務來做均衡負責，每臺服務器中安裝了apache來做服務端接受處理，每臺apache最大可以處理大約2000條連接。因此理論上目前網站或者APP可以處理大于4000個用戶請求。如果要支持同時1萬的請求，則需要5臺apache服務器來支持,因此目前缺少6臺web服務器。

升級服務器后的訪問示意圖

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

1)主從分離解決主庫80%的查詢壓力。目前平臺官網、APP均連接mysql主庫導致主庫壓力倍增，把服務中的查詢全部遷移到從數據庫可以大量減輕主庫的壓力。

2)增加緩存服務器。當從庫查詢到達峰值的時候，也會影響主從的同步，從而影響交易，因此對用戶經常使用的查詢進行緩存以達到減少數據庫的請求壓力。需要新增三臺緩存服務器搭建redis集群。

3、其它優化1）官網首頁靜態化，從cnzz統計來分析，首頁占比網站的整體訪問量的15%左右，對于首頁不經常變動的數據通過靜態化來處理，提升官網打開的流暢度。

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

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

6 服務器升級方案

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

2、增加緩存減少數據的壓力，需要新增兩臺大內存的緩存服務器

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

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

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

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

優化方案文檔下載