背景

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

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

解決方案

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

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

其次，我們資源架構層面需要做如下準備：

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

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

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

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

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

最后，應用層面要做如下準備：

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

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

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

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

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

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

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

總結

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

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

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