背景

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

本人曾面對過幾千大并發請求和客戶這邊搞活動出現問題的經驗教訓。希望能通過這些經驗教訓帶來的優化改善能幫助更多的企業去解除搞活動時帶來的焦慮。

解決方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

06提前load可能的熱點數據進Redis，或者延長過期時間。

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

總結

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

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

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