背景

零售行業(yè)通常會(huì)面臨618、雙十一、周年慶等活動(dòng)。在面對(duì)這些重要的活動(dòng)通常會(huì)擔(dān)心資源是否需要擴(kuò)容？應(yīng)用能否抗住大并發(fā)的請(qǐng)求？

本人曾面對(duì)過幾千大并發(fā)請(qǐng)求和客戶這邊搞活動(dòng)出現(xiàn)問題的經(jīng)驗(yàn)教訓(xùn)。希望能通過這些經(jīng)驗(yàn)教訓(xùn)帶來的優(yōu)化改善能幫助更多的企業(yè)去解除搞活動(dòng)時(shí)帶來的焦慮。

解決方案

搞活動(dòng)前我們要做一些準(zhǔn)備工作，這些工作能有效避免我們的應(yīng)用在搞活動(dòng)時(shí)出現(xiàn)的各種狀況。

首先，我們要準(zhǔn)備一套和生產(chǎn)一致的環(huán)境作為壓測使用。壓測的目的就是模擬實(shí)際活動(dòng)的請(qǐng)求，看看是否能抗住活動(dòng)帶來的并發(fā)壓力。這里要注意的是，壓測必須按實(shí)際可能的請(qǐng)求來，如果只是單純的壓幾個(gè)活動(dòng)中涉及接口是無法完全暴露真實(shí)請(qǐng)求可能出現(xiàn)的問題的。

其次，我們資源架構(gòu)層面需要做如下準(zhǔn)備：

01所有資源按照壓測后由DevOps和壓測人員以及研發(fā)負(fù)責(zé)人評(píng)估后給出資源的配置，包括容器的limit限制。

02虛擬機(jī)和K8S環(huán)境要求開啟彈性伸縮，彈性伸縮的配置由DevOps和研發(fā)負(fù)責(zé)人評(píng)估后給出。

03數(shù)據(jù)庫和其他中間件如果是共享實(shí)例需要評(píng)估如果出問題影響面大不大，如果影響面大需要在活動(dòng)前至少一周做遷移，待活動(dòng)后再遷回。如果活動(dòng)會(huì)在一年內(nèi)頻繁開展建議單獨(dú)實(shí)例并降低配置。

04云上數(shù)據(jù)庫需開啟讀寫分離功能，并且提前一周左右測試確認(rèn)數(shù)據(jù)的一致性問題。

05云上數(shù)據(jù)庫如果無法通過壓測確認(rèn)配置則需開啟彈性擴(kuò)展配置，并確認(rèn)彈性升配的中斷時(shí)間應(yīng)用可接受。單獨(dú)實(shí)例開啟，共享實(shí)例不開啟。

最后，應(yīng)用層面要做如下準(zhǔn)備：

01使用容器應(yīng)用網(wǎng)關(guān)的，需開啟熔斷限流。并進(jìn)行測試評(píng)估開啟后觸發(fā)的影響。用于確保應(yīng)用不會(huì)被打爆。指標(biāo)由DevOps和壓測人員以及研發(fā)負(fù)責(zé)人評(píng)估后給出。

02如果有非正常的請(qǐng)求，應(yīng)用層面需做Block防護(hù)，例如同一個(gè)用戶ID同一秒發(fā)出超過10次優(yōu)惠券請(qǐng)求的API，我們認(rèn)為是非人為操作，需Block賬戶。

03如果有大量正常請(qǐng)求訪問應(yīng)用，應(yīng)用層面可以設(shè)置排隊(duì)頁面緩存，按請(qǐng)求進(jìn)入的先后次序分批放請(qǐng)求到后端緩存或數(shù)據(jù)庫。比如一次放500個(gè)請(qǐng)求，處理完了再放500個(gè)。這樣既可以避免應(yīng)用奔潰也能避免后端緩存或數(shù)據(jù)庫扛不住。

04如果有大量正常請(qǐng)求是到數(shù)據(jù)庫取同樣數(shù)據(jù)的則要把這些數(shù)據(jù)在第一次請(qǐng)求后放到緩存里，請(qǐng)求先到緩存，緩存里沒有再到數(shù)據(jù)庫，數(shù)據(jù)庫有更新讓請(qǐng)求到數(shù)據(jù)庫來拿數(shù)據(jù)，緩存更新后再恢復(fù)到緩存取數(shù)據(jù)。這樣可以減少數(shù)據(jù)庫的壓力。

05根據(jù)壓測反饋的慢SQL，提前建立好必要的索引。

06提前l(fā)oad可能的熱點(diǎn)數(shù)據(jù)進(jìn)Redis，或者延長過期時(shí)間。

07對(duì)于key在redis不存在，數(shù)據(jù)庫也不存在的數(shù)據(jù)，策略可以是賦值null寫回redis，防止以不存在的id惡意攻擊打垮數(shù)據(jù)庫。

總結(jié)

活動(dòng)前的準(zhǔn)備工作要從資源架構(gòu)和應(yīng)用兩方面著手去準(zhǔn)備。以應(yīng)用層面的優(yōu)化準(zhǔn)備工作優(yōu)先，資源架構(gòu)優(yōu)化準(zhǔn)備為輔。

因?yàn)橘Y源本身并不能解決大并發(fā)的問題，只是提供一個(gè)承載環(huán)境。如果有一些很嚴(yán)重的慢SQL，資源架構(gòu)優(yōu)化的再好也有會(huì)被打爆的一天。

所以，我們一定要把主要精力放在應(yīng)用架構(gòu)的優(yōu)化上。兩者結(jié)合我們將不再為搞活動(dòng)而感到焦慮，可以專注于業(yè)務(wù)的推動(dòng)。