一次生產事故的優化經歷

01-26

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

用戶搶標的時候問題集中在以下幾個方面

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伺服器。

升級伺服器後的訪問示意圖