在一次正常的活動促(cu)銷之后，客服(fu)開始陸續反(fan)(fan)饋有用戶反(fan)(fan)應在搶(qiang)標的時(shi)候打不(bu)開網(wang)頁(ye)或者 APP，在打開的時(shi)候標的就已(yi)經被搶(qiang)光了。

剛開始沒有特(te)別的(de)上心，覺得搶標不(bu)就是(shi)這樣嗎(ma)，搶小(xiao)米手機的(de)時候不(bu)也是(shi)這樣嗎(ma)？

隨(sui)著活動繼續推進，有(you)更(geng)多的用(yong)戶(hu)強烈(lie)抗(kang)議，用(yong)戶(hu)領了加息(xi)券或者抵現券之后搶不上標的，認為是平臺作假(jia)故意不讓(rang)他們使(shi)用(yong)以達到節(jie)省資源。

 

分析過程

 

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

我(wo)們前端一共有三款產品：APP、官(guan)網和(he) H5，其(qi)中(zhong) APP 使(shi)用(yong)量(liang)最(zui)大，官(guan)網其(qi)次，H5 平(ping)時使(shi)用(yong)量(liang)極少但是做活動期間(jian)流量(liang)會暴增（活動一般都是 H5 游戲(xi)居多，H5 也(ye)便于(yu)推(tui)廣營銷）。

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

首先(xian)懷疑網絡帶寬是否(fou)被涌(yong)滿，找(zhao)到網絡工程師通過工具來監控，在搶(qiang)標的(de)時候帶寬最高使用(yong)率只有(you) 70% 左右，隨排除之。

再次懷疑(yi) Web 服(fu)務器(qi)是否抗(kang)不住(zhu)了(le)，使(shi)用 top 命令(ling)查看官網負載的兩臺(tai)服(fu)務器(qi)，在搶標(biao)的瞬間會飆到(dao) 6-8 左(zuo)右，搶標(biao)后(hou)也慢慢的恢復了(le)正常(chang)，APP 兩臺(tai)服(fu)務器(qi)高峰到(dao) 10-12，隨后(hou)也恢復正常(chang)。

跟(gen)蹤 Web 服務器業務日志，發現在數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)庫更新層報請(qing)求(qiu)不到新的(de)數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)庫連接(jie)或者數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)庫連接(jie)已經(jing)用完，認為是數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)庫的(de)最大連接(jie)數(shu)(shu)(shu)(shu)(shu)太小，于是調(diao)整 MySQL 數(shu)(shu)(shu)(shu)(shu)據(ju)(ju)庫最大連接(jie)數(shu)(shu)(shu)(shu)(shu)為以往的(de) 3 倍。

下次搶標的(de)時候繼續觀(guan)察(cha)業務日志(zhi)，發現(xian)已經不(bu)報數據庫連接的(de)相關錯(cuo)誤了，但還是很多用戶反饋(kui)搶標時候打不(bu)開頁面。

繼續(xu)跟(gen)蹤 Web 服(fu)務器，在搶標(biao)時使用命令（ps -ef|grep httpd|wc -l）查(cha)看 httpd 的(de)連接數有 1000 左右，隨機(ji)查(cha)看 Apache 配置文件中設置的(de)最大連接數為(wei) 1024（Apache 默認(ren)的(de)最大連接數為(wei) 256）。

原來搶標期間連(lian)接(jie)數(shu)已經(jing)到達最(zui)大連(lian)接(jie)數(shu)，很多(duo)用戶在(zai)搶標的過程中已經(jing)獲取不到 http 連(lian)接(jie)導致(zhi)頁(ye)面無響應(ying)或(huo)者 APP 一直在(zai)等待中。于(yu)是調整 Apache 配置文(wen)件中的最(zui)大連(lian)接(jie)數(shu)為(wei) 1024*3。

在搶(qiang)(qiang)標(biao)過(guo)程中繼續觀察，Apache 的(de)連接數(shu)在搶(qiang)(qiang)標(biao)的(de)時候仍(reng)(reng)然可以飆到 2600-2800 之間，根據客(ke)服反(fan)饋，仍(reng)(reng)然有很(hen)多用戶反(fan)饋搶(qiang)(qiang)標(biao)的(de)問題，但比之前稍(shao)微好一點，但是(shi)有零(ling)星的(de)用戶反(fan)饋已(yi)經(jing)搶(qiang)(qiang)到標(biao)的(de)，最后又(you)給回退了(le)。

然后繼續觀察(cha)數據(ju)庫(ku)服(fu)務器，使(shi)用 top 命令和 MySQL Workbench 查看 MySQL 主庫(ku)和從(cong)庫(ku)的各(ge)項負載(zai)嚇(xia)一(yi)跳（如下圖），MySQL 服(fu)務器主庫(ku)的各(ge)項指標(biao)均已經達(da)到峰值，而從(cong)庫(ku)幾(ji)乎沒有(you)太大壓力(li)。

跟蹤(zong)代(dai)碼(ma)發(fa)現，三端的(de)業(ye)務代(dai)碼(ma)全(quan)部連接主(zhu)庫(ku)，從庫(ku)只有后臺的(de)查(cha)詢(xun)業(ye)務在使用，于是立刻啟動改造。