一次生產事故的最佳化經歷

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