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

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

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

分析過程

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

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

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

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

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

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

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

繼續(xù)跟蹤 Web 辦事器，在搶標(biāo)時(shí)使用命令（ps -ef|grep httpd|wc -l）查看 httpd 的連接數(shù)有 1000 擺布，隨機(jī)查看 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)的時(shí)候仍然可以飆到 2600-2800 之間，，按照客服反饋，仍然有很多用戶反饋搶標(biāo)的問題，但比之前稍微好一點(diǎn)，但是有零星的用戶反饋已經(jīng)搶到標(biāo)的，最后又給回退了。

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

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

標(biāo)簽：東營 烏魯木齊 林芝 九江 鹽城