在一次正常的活動(dòng)促銷之后，客服開始陸續(xù)反饋有用戶反應(yīng)在搶標(biāo)的時(shí)候打不開網(wǎng)頁或者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é)省資源。

分析過程

其實(shí)以前也會(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服務(wù)器中（如下圖），這次用戶反饋基本在web和app端，所以重點(diǎn)觀察這四臺(tái)服務(wù)器。

首先懷疑網(wǎng)絡(luò)帶寬是否被涌滿，找到網(wǎng)絡(luò)工程師通過工具來監(jiān)控，在搶標(biāo)的時(shí)候帶寬最高使用率只有70%左右，隨排除之；再次懷疑web服務(wù)器是否抗不住了，使用top命令查看官網(wǎng)負(fù)載的兩臺(tái)服務(wù)器，在搶標(biāo)的瞬間會(huì)飆到6-8左右，搶標(biāo)后也慢慢的恢復(fù)了正常，app兩臺(tái)服務(wù)器高峰到10-12，隨后也恢復(fù)正常。

跟蹤web服務(wù)器業(yè)務(wù)日志，發(fā)現(xiàn)在數(shù)據(jù)庫更新層報(bào)請(qǐng)求不到新的數(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)錯(cuò)誤了，但還是很多用戶反饋搶標(biāo)時(shí)候打不開頁面。

繼續(xù)跟蹤web服務(wù)器，在搶標(biāo)時(shí)使用命令（ps -ef|grep httpd|wc -l）查看httpd得連接數(shù)有1千左右，隨機(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之間，根據(jù)客服反饋，仍然有很多用戶反饋搶標(biāo)的問題，但比之前稍微好一點(diǎn)，但是有零星的用戶反饋已經(jīng)搶到標(biāo)的，最后又給回退了。然后繼續(xù)觀察數(shù)據(jù)庫服務(wù)器，使用top命令和MySQLWorkbench查看mysql主庫和從庫的各項(xiàng)負(fù)載嚇一跳（如下圖），mysql服務(wù)器主庫的各項(xiàng)指標(biāo)均已經(jīng)達(dá)到峰值，而從庫幾乎沒有太大壓力。

跟蹤代碼發(fā)現(xiàn)，三端的業(yè)務(wù)代碼全部連接主庫，從庫只有后臺(tái)的查詢業(yè)務(wù)在使用，于是立刻啟動(dòng)改造；將除過搶標(biāo)過程中的查詢外，其它頁面或者業(yè)務(wù)的所有查詢改造為查詢從庫，改造之后觀察，發(fā)現(xiàn)主庫的壓力明顯減少，從庫的壓力開始上來了。如下圖：

根據(jù)客服的反饋，改造之后搶到標(biāo)回退的問題幾乎沒有了，搶標(biāo)過程中頁面打不開或者打開慢的問題有一定的緩解但仍有部分用戶反饋此問題，根據(jù)上面各項(xiàng)目分析結(jié)果得出：

當(dāng)時(shí)根據(jù)這些情況寫了一份優(yōu)化的報(bào)告,見下文：

優(yōu)化報(bào)告

1 背景

隨著公司業(yè)務(wù)不斷發(fā)展，業(yè)務(wù)量和用戶量的激增，官網(wǎng)pv也從最初的xxx-xxx到現(xiàn)在的xxx-xxxx，APP活躍用戶更是大幅增加；因此也對(duì)平臺(tái)目前的技術(shù)架構(gòu)有了更大的挑戰(zhàn)。特別是近期平臺(tái)標(biāo)源緊張的情況下，滿標(biāo)的時(shí)間更是越來越短。服務(wù)器的壓力也越來越大；因此需要升級(jí)目前的系統(tǒng)架構(gòu)，以支持更大的用戶量和業(yè)務(wù)量。

2 用戶訪問示意圖

目前平臺(tái)有三款產(chǎn)品面對(duì)用戶，平臺(tái)官網(wǎng)、平臺(tái)APP、平臺(tái)小網(wǎng)頁；其中平臺(tái)官網(wǎng)和平臺(tái)APP的壓力比較大。

3 存在的問題

用戶搶標(biāo)的時(shí)候問題集中在以下幾個(gè)方面1、網(wǎng)頁或者APP打不開2、網(wǎng)站或者APP打開慢3、搶標(biāo)過程中轉(zhuǎn)賬成功后，因?yàn)榉?wù)器負(fù)責(zé)壓力大更新失敗，再次退款4、數(shù)據(jù)庫連接數(shù)用完，導(dǎo)致滿標(biāo)后添加投資記錄失敗，回退標(biāo)的進(jìn)度

4、分析

通過對(duì)近期的服務(wù)器參數(shù)，并發(fā)量，以及系統(tǒng)日志等進(jìn)行深入的分析，得出：1、平臺(tái)官網(wǎng)、平臺(tái)APP搶標(biāo)過程中服務(wù)器壓力巨大，其中平臺(tái)APP問題更加突出，搶標(biāo)高峰期間單臺(tái)APP服務(wù)器apache最大連接數(shù)已經(jīng)接近2600，接近apache最大的處理能力

2、數(shù)據(jù)庫服務(wù)器壓力巨大。數(shù)據(jù)庫壓力主要在兩個(gè)時(shí)期比較突出1）當(dāng)平臺(tái)做活動(dòng)的時(shí)候，官網(wǎng)、小網(wǎng)頁、APP訪問量巨增，導(dǎo)致數(shù)據(jù)查詢量跟著巨增，當(dāng)?shù)竭_(dá)數(shù)據(jù)庫處理極限時(shí)，就會(huì)表現(xiàn)出網(wǎng)站打開慢等問題；2）當(dāng)用戶搶標(biāo)的時(shí)候，用戶搶標(biāo)的壓力又分為兩個(gè)階段：搶標(biāo)前和搶標(biāo)中。搶標(biāo)前，因?yàn)闈M標(biāo)速度很快，用戶提前打開搶標(biāo)頁面不斷刷新，這樣數(shù)據(jù)庫的查詢壓力會(huì)不斷增大，如果搶標(biāo)的用戶量非常大，會(huì)導(dǎo)致在搶標(biāo)之前將數(shù)據(jù)庫連接數(shù)用完；搶標(biāo)中，單次購(gòu)買大概會(huì)涉及15張左右表進(jìn)行更改查詢，每個(gè)標(biāo)的份額1000萬大概每次會(huì)有100-200人左右購(gòu)買完成滿標(biāo)，以中間值150人計(jì)算，在幾秒的時(shí)間內(nèi)需要對(duì)數(shù)據(jù)更新2000-3000次(僅僅是更新，不包括查詢 )，產(chǎn)生大量并發(fā)，可能會(huì)導(dǎo)致更新失敗或者連接超時(shí)，從而影響到用戶投標(biāo)和系統(tǒng)正常滿標(biāo)。

5 解決方案

1、web服務(wù)器解決方案單個(gè)用戶訪問web服務(wù)的示意圖

目前網(wǎng)站和平臺(tái)APP均是采用了兩臺(tái)服務(wù)來做均衡負(fù)責(zé)，每臺(tái)服務(wù)器中安裝了apache來做服務(wù)端接受處理，每臺(tái)apache最大可以處理大約2000條連接。因此理論上目前網(wǎng)站或者APP可以處理大于4000個(gè)用戶請(qǐng)求。如果要支持同時(shí)1萬的請(qǐng)求，則需要5臺(tái)apache服務(wù)器來支持,因此目前缺少6臺(tái)web服務(wù)器。

升級(jí)服務(wù)器后的訪問示意圖

2、數(shù)據(jù)庫解決方案當(dāng)前數(shù)據(jù)庫的部署方案

1)主從分離解決主庫80%的查詢壓力。目前平臺(tái)官網(wǎng)、APP均連接mysql主庫導(dǎo)致主庫壓力倍增，把服務(wù)中的查詢?nèi)窟w移到從數(shù)據(jù)庫可以大量減輕主庫的壓力。

2)增加緩存服務(wù)器。當(dāng)從庫查詢到達(dá)峰值的時(shí)候，也會(huì)影響主從的同步，從而影響交易，因此對(duì)用戶經(jīng)常使用的查詢進(jìn)行緩存以達(dá)到減少數(shù)據(jù)庫的請(qǐng)求壓力。需要新增三臺(tái)緩存服務(wù)器搭建redis集群。

3、其它優(yōu)化1）官網(wǎng)首頁靜態(tài)化，從cnzz統(tǒng)計(jì)來分析，首頁占比網(wǎng)站的整體訪問量的15%左右，對(duì)于首頁不經(jīng)常變動(dòng)的數(shù)據(jù)通過靜態(tài)化來處理，提升官網(wǎng)打開的流暢度。

2）apache服務(wù)器的優(yōu)化，開啟gzip壓縮，配置合理的鏈接數(shù)等

3) 去掉投資過程中的更新熱點(diǎn)：標(biāo)的進(jìn)度表。每次投標(biāo)成功或者失敗都需要對(duì)標(biāo)的進(jìn)度表進(jìn)行更新，多線程更新的時(shí)候就會(huì)出現(xiàn)樂觀鎖等問題。去掉過程中的更新，只在滿標(biāo)后將標(biāo)的進(jìn)度信息保存在標(biāo)的進(jìn)度表，優(yōu)化投資過程中對(duì)數(shù)據(jù)庫的壓力。

6 服務(wù)器升級(jí)方案

1、平臺(tái)最大的壓力來自于數(shù)據(jù)庫，需要將現(xiàn)在的一主一從，改為一主四從。官網(wǎng)/app/小網(wǎng)頁產(chǎn)生的大量查詢，由虛IP分發(fā)到三臺(tái)從庫，后臺(tái)管理查詢走另外的一個(gè)從庫。數(shù)據(jù)庫需要新增三臺(tái)服務(wù)器數(shù)據(jù)庫升級(jí)后的示意圖

2、增加緩存減少數(shù)據(jù)的壓力，需要新增兩臺(tái)大內(nèi)存的緩存服務(wù)器

3、需要新增三臺(tái)web服務(wù)器分解用戶訪問請(qǐng)求

app需要新增兩臺(tái)服務(wù)器在搶標(biāo)過程中app服務(wù)器壓力最大，需要新增兩臺(tái)服務(wù)器，配置完成后的示意圖

官網(wǎng)需要新增一臺(tái)服務(wù)器官網(wǎng)在搶標(biāo)過程也有一定的壓力，需要新增一條服務(wù)器，完成后示意圖如下：

總合計(jì)之后需要購(gòu)置8臺(tái)服務(wù)器，其中有兩臺(tái)要求有大內(nèi)存（64G以上）

優(yōu)化方案文檔下載