在一次正常的活動促銷之后，客服開始陸續(xù)反饋有用戶反應(yīng)在搶標(biāo)的時候打不開網(wǎng)頁或者 APP，在打開的時候標(biāo)的就已經(jīng)被搶光了。

剛開始沒有特別的上心，覺得搶標(biāo)不就是這樣嗎，搶小米手機的時候不也是這樣嗎？

隨著活動繼續(xù)推進，有更多的用戶強烈抗議，用戶領(lǐng)了加息券或者抵現(xiàn)券之后搶不上標(biāo)的，認(rèn)為是平臺作假故意不讓他們使用以達(dá)到節(jié)省資源。

 

分析過程

 

以前也會有陸續(xù)的用戶反饋不減少的情況，給客戶以小米搶手機為例子解釋就過去了，這次用戶反饋太過強烈，才讓我們重視了起來。

我們前端一共有三款產(chǎn)品：APP、官網(wǎng)和 H5，其中 APP 使用量最大，官網(wǎng)其次，H5 平時使用量極少但是做活動期間流量會暴增（活動一般都是 H5 游戲居多，H5 也便于推廣營銷）。

前端的三款產(chǎn)品都是分別使用 LVS 負(fù)載到后端的兩臺 Web 服務(wù)器中（如下圖），這次用戶反饋基本在 Web 和 APP 端，所以重點觀察這四臺服務(wù)器。

首先懷疑網(wǎng)絡(luò)帶寬是否被涌滿，找到網(wǎng)絡(luò)工程師通過工具來監(jiān)控，在搶標(biāo)的時候帶寬最高使用率只有 70% 左右，隨排除之。

再次懷疑 Web 服務(wù)器是否抗不住了，使用 top 命令查看官網(wǎng)負(fù)載的兩臺服務(wù)器，在搶標(biāo)的瞬間會飆到 6-8 左右，搶標(biāo)后也慢慢的恢復(fù)了正常，APP 兩臺服務(wù)器高峰到 10-12，隨后也恢復(fù)正常。

跟蹤 Web 服務(wù)器業(yè)務(wù)日志，發(fā)現(xiàn)在數(shù)據(jù)庫更新層報請求不到新的數(shù)據(jù)庫連接或者數(shù)據(jù)庫連接已經(jīng)用完，認(rèn)為是數(shù)據(jù)庫的最大連接數(shù)太小，于是調(diào)整 MySQL 數(shù)據(jù)庫最大連接數(shù)為以往的 3 倍。

下次搶標(biāo)的時候繼續(xù)觀察業(yè)務(wù)日志，發(fā)現(xiàn)已經(jīng)不報數(shù)據(jù)庫連接的相關(guān)錯誤了，但還是很多用戶反饋搶標(biāo)時候打不開頁面。

繼續(xù)跟蹤 Web 服務(wù)器，在搶標(biāo)時使用命令（ps -ef|grep httpd|wc -l）查看 httpd 的連接數(shù)有 1000 左右，隨機查看 Apache 配置文件中設(shè)置的最大連接數(shù)為 1024（Apache 默認(rèn)的最大連接數(shù)為 256）。

原來搶標(biāo)期間連接數(shù)已經(jīng)到達(dá)最大連接數(shù)，很多用戶在搶標(biāo)的過程中已經(jīng)獲取不到 http 連接導(dǎo)致頁面無響應(yīng)或者 APP 一直在等待中。于是調(diào)整 Apache 配置文件中的最大連接數(shù)為 1024*3。

在搶標(biāo)過程中繼續(xù)觀察，Apache 的連接數(shù)在搶標(biāo)的時候仍然可以飆到 2600-2800 之間，根據(jù)客服反饋，仍然有很多用戶反饋搶標(biāo)的問題，但比之前稍微好一點，但是有零星的用戶反饋已經(jīng)搶到標(biāo)的，最后又給回退了。

然后繼續(xù)觀察數(shù)據(jù)庫服務(wù)器，使用 top 命令和 MySQL Workbench 查看 MySQL 主庫和從庫的各項負(fù)載嚇一跳（如下圖），MySQL 服務(wù)器主庫的各項指標(biāo)均已經(jīng)達(dá)到峰值，而從庫幾乎沒有太大壓力。

跟蹤代碼發(fā)現(xiàn)，三端的業(yè)務(wù)代碼全部連接主庫，從庫只有后臺的查詢業(yè)務(wù)在使用，于是立刻啟動改造。