POST TIME:2018-12-03 17:19
在一次正常的活動(dòng)促銷之后,客服開始陸續(xù)反饋有用戶反應(yīng)在搶標(biāo)的時(shí)候打不開網(wǎng)頁(yè)或者 APP,在打開的時(shí)候標(biāo)的就已經(jīng)被搶光了。
剛開始沒有特另外上心,覺得搶標(biāo)不就是這樣嗎,搶小米手機(jī)的時(shí)候不也是這樣嗎?
隨著活動(dòng)繼續(xù)推進(jìn),有更多的用戶強(qiáng)烈抗議,用戶領(lǐng)了加息券或者抵現(xiàn)券之后搶不上標(biāo)的,認(rèn)為是平臺(tái)作假故意不讓他們使用以達(dá)到節(jié)省資源。
分析過程
以前也會(huì)有陸續(xù)的用戶反饋不減少的情況,給客戶以小米搶手機(jī)為例子解釋就過去了,這次用戶反饋太過強(qiáng)烈,才讓我們重視了起來。
我們前端一共有三款產(chǎn)品:APP、官網(wǎng)和 H5,其中 APP 使用量最大,官網(wǎng)其次,H5 平時(shí)使用量極少但是做活動(dòng)期間流量會(huì)暴增(活動(dòng)一般都是 H5 游戲居多,H5 也便于推廣營(yíng)銷)。
前端的三款產(chǎn)品都是別離使用 LVS 負(fù)載到后端的兩臺(tái) Web 辦事器中(如下圖),這次用戶反饋基本在 Web 和 APP 端,所以重點(diǎn)不雅觀察這四臺(tái)辦事器。
首先懷疑網(wǎng)絡(luò)帶寬是否被涌滿,找到網(wǎng)絡(luò)工程師通過工具來監(jiān)控,在搶標(biāo)的時(shí)候帶寬最高使用率只有 70% 擺布,隨排除之。
再次懷疑 Web 辦事器是否抗不住了,使用 top 命令查看官網(wǎng)負(fù)載的兩臺(tái)辦事器,在搶標(biāo)的瞬間會(huì)飆到 6-8 擺布,搶標(biāo)后也慢慢的恢復(fù)了正常,APP 兩臺(tái)辦事器高峰到 10-12,隨后也恢復(fù)正常。
跟蹤 Web 辦事器業(yè)務(wù)日志,發(fā)現(xiàn)在數(shù)據(jù)庫(kù)更新層報(bào)請(qǐng)求不到新的數(shù)據(jù)庫(kù)連接或者數(shù)據(jù)庫(kù)連接已經(jīng)用完,認(rèn)為是數(shù)據(jù)庫(kù)的最大連接數(shù)太小,于是調(diào)整 MySQL 數(shù)據(jù)庫(kù)最大連接數(shù)為以往的 3 倍。
下次搶標(biāo)的時(shí)候繼續(xù)不雅觀察業(yè)務(wù)日志,發(fā)現(xiàn)已經(jīng)不報(bào)數(shù)據(jù)庫(kù)連接的相關(guān)錯(cuò)誤了,但還是很多用戶反饋搶標(biāo)時(shí)候打不開頁(yè)面。
繼續(xù)跟蹤 Web 辦事器,在搶標(biāo)時(shí)使用命令(ps -ef|grep httpd|wc -l)查看 httpd 的連接數(shù)有 1000 擺布,隨機(jī)查看 Apache 配置文件中設(shè)置的最大連接數(shù)為 1024(Apache 默認(rèn)的最大連接數(shù)為 256)。
本來?yè)寴?biāo)期間連接數(shù)已經(jīng)到達(dá)最大連接數(shù),很多用戶在搶標(biāo)的過程中已經(jīng)獲取不到 http 連接導(dǎo)致頁(yè)面無響應(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ù)庫(kù)辦事器,使用 top 命令和 MySQL Workbench 查看 MySQL 主庫(kù)和從庫(kù)的各項(xiàng)負(fù)載嚇一跳(如下圖),MySQL 辦事器主庫(kù)的各項(xiàng)指標(biāo)均已經(jīng)達(dá)到峰值,而從庫(kù)幾乎沒有太大壓力。
跟蹤代碼發(fā)現(xiàn),三端的業(yè)務(wù)代碼全部連接主庫(kù),從庫(kù)只有后臺(tái)的查詢業(yè)務(wù)在使用,于是立刻啟動(dòng)改造。