在一次正常的活動促銷之後，客服開始陸續反饋有用戶反應在搶標的時候打不開網頁或者APP，在打開的時候標的就已經被搶光了，剛開始沒有特別的上心，覺得搶標不就是這樣嗎，搶小米手機的時候也不就這樣嗎？隨著活動繼續推進，有更多的用戶強烈抗議，用戶領了加息卷或抵現卷之後搶不上標的，認為是平台作假故意不讓使用以達到節省資源。
其實以前也會有陸續的用戶回饋不減少，給客戶以小米搶手機為例子忽悠了過去，這次用戶回饋太過強烈，才讓我們重視了起來。我們前端共三款產品，app、官網、H5，其中app使用量最大，官網其次，H5平時使用量極少但是做活動期間流量會暴增（活動一般都是H5遊戲居多，H5也便於推廣行銷）,前端的三款產品都是分別使用lvs負載到後端的兩台web服務器中（如下圖），這次用戶反饋基本上在web和app端，所以重點觀察這四台伺服器.
首先懷疑網路頻寬是否被湧滿，找到網路工程師透過工具來監控，在搶標的時候頻寬最高使用率只有70%左右，隨排除之；再次懷疑web伺服器是否抗不住了，使用top命令查看官網負載的兩台伺服器，在搶標的瞬間會飆到6-8左右，搶標後也慢慢的恢復正常，app兩台伺服器高峰到10-12，隨後也恢復正常了。
追蹤web伺服器業務日誌，發現在資料庫更新層報請求不到新的資料庫連線或資料庫連線已經用完，認為是資料庫的最大連線數太小，於是調整mysql資料庫最大連線數為以往的3倍；下次搶標的時候繼續觀察業務日誌，發現已經不報資料庫連結的相關錯誤了，但還是很多使用者回饋搶標時候打不開頁面。
繼續追蹤網頁伺服器，在搶標時使用指令（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 徹底解決這些問題，需要綜合考慮平台的整體優化，如：業務優化（去掉業務中熱點）、增加快取、部分頁面靜態化（可以使用雅虎和谷歌的前端優化規則，網路上也有很多的測試網站可以評測）等等。
當時根據這些情況寫了一份優化的報告,見下文：
隨著公司業務不斷發展，業務量和用戶量的激增，官網pv也從最初的xxx-xxx到現在的xxx-xxxx，APP活躍用戶更是大幅增加；因此也對平台目前的技術架構有了更大的挑戰。特別是近期平台標源緊張的情況下，滿標的時間更是越來越短。伺服器的壓力也越來越大；因此需要升級目前的系統架構，以支援更大的用戶量和業務量。
目前平台有三款產品面對用戶，平台官網、平台APP、平台小網頁；其中平台官網和平台APP的壓力比較大。
用戶搶標的時候問題集中在以下幾個方面
1、網頁或APP打不開
2、網站或APP開啟慢
3、搶標過程中轉帳成功後，因為伺服器負責壓力大更新失敗，再次退款
4、資料庫連線數用完，導致滿標後加入投資記錄失敗，回退標的進度
透過對近期的伺服器參數，並發量，以及系統日誌等進行深入的分析，得出：
1、平台官網、平台APP搶標過程中伺服器壓力巨大，其中平台APP問題更加突出，搶標高峰期間單一APP伺服器apache最大連線數已接近2600，接近apache最大的處理能力
2、資料庫伺服器壓力巨大。資料庫壓力主要在兩個時期比較突出
1）當平台做活動的時候，官網、小網頁、APP訪問量巨增，導致資料查詢量跟著巨增，當到達資料庫處理極限時，就會表現出網站開慢等問題；
2）當用戶搶標的時候，用戶搶標的壓力又分為兩個階段：搶標前和搶標中。搶標前，因為滿標速度很快，用戶提前打開搶標頁面不斷刷新，這樣資料庫的查詢壓力會不斷增大，如果搶標的用戶量非常大，會導致在搶標之前將資料庫連接數用完；搶標中，單次購買大概會涉及15張左右表進行更改查詢，每個標的份額1000萬大概每次會有100-200人左右購買完成滿標，以中間值150人計算，在幾秒的時間內需要對資料更新2000-3000次(僅僅是更新，不包括查詢)，產生大量並發，可能會導致更新失敗或連接逾時，從而影響到用戶投標和系統正常滿標。
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) 去掉投資過程中的更新熱點：標的進度表。每次投標成功或失敗都需要對標的進度表進行更新，多執行緒更新的時候就會出現樂觀鎖等問題。去掉過程中的更新，只在滿標後將標的進度資訊保存在標的進度表，優化投資過程中對資料庫的壓力。
1、平台最大的壓力來自資料庫，需要將現在的一主一從，改為一主四從。官網/app/小網頁產生的大量查詢，由虛擬IP分發到三台從庫，後台管理查詢走另外的一個從庫。資料庫需要新增三台伺服器
資料庫升級後的示意圖
2、增加快取減少資料的壓力，需要新增兩台大記憶體的快取伺服器
3、需要新增三台網頁伺服器分解使用者存取請求
app需要新增兩台伺服器
在搶標過程中app伺服器壓力最大，需要新增兩台伺服器，設定完成後的示意圖
官網需要新增一台伺服器
官網在搶標過程也有一定的壓力，需要新增一台伺服器，完成後示意圖如下：
總合計之後需要購置8台伺服器，其中有兩台要求有大記憶體（64G以上）
點擊下載優化報告word版本
#備註：所有優化方案投產後，問題解決，搶標無憂！
作者：純潔的微笑
出處：http://www.php.cn/
版權所有，轉載請註明出處
以上是一次生產事故的優化經歷的詳細內容。更多資訊請關注PHP中文網其他相關文章！
