談談秒殺系統的落地方案

昨天的文章給秒殺系列開了一個頭,今天會集中講一下實現一個秒殺系統的思路和方案,不表明這就是最好的方案或者最佳實踐,而是但願經過這篇文章,能起到拋磚引玉的做用,但願有更佳的思路提供出來。前端


秒殺系統要解決的技術挑戰數據庫

1. 短期內的超高訪問量對後臺服務的衝擊。秒殺期間,來自外部請求產生的QPS會是平時的10~100倍。後端

2. 數據庫的讀寫壓力陡增。大量的併發寫,會形成數據庫的行鎖處於沒法釋放的狀態,大量的線程排隊進而形成服務請求超時失敗。瀏覽器

3. 網絡帶寬資源會由於秒殺被大量佔據掉。假設秒殺頁面的大小爲150K,若是最大併發鏈接數爲20000,那麼應用服務器至少須要支持的帶寬>3G。緩存


秒殺系統開發前的準備
服務器


1. 全部頁面的靜態資源走CDN,CSS, JS和圖片放入CDN後,利用遍及全國的CDN節點,下降帶寬和靜態服務器的壓力,避免網絡帶寬成爲業務瓶頸。微信

2. 準備獨立的服務器,秒殺系統單獨部署,包括使用單獨域名,避免秒殺業務對正常業務的系統的衝擊和影響。網絡

3. 創建性能測試的環境,上線前根據本次秒殺的業務目標和流量預估,制定性能測試計劃,只有經過性能測試後,才能真正上線。
架構


秒殺系統的架構設計
併發


1. 前端的設計

在整個活動過程當中,前端頁面應該是以下狀態:


秒殺開始前,秒殺按鈕灰掉爲「未開始」,不可點擊。

秒殺進行中,秒殺按鈕能夠點擊下單。

秒殺結束後,秒殺按鈕灰掉爲「已結束」,不可點擊。


因此咱們須要作如下幾件事:


1. 秒殺產品的介紹,詳情,參數等等,所有靜態化,切勿經過後臺API查詢更新,減輕後端的壓力。

2. 用戶點擊「下單」後,按鈕置灰,禁止用戶重複提交請求,限制用戶在60秒以內只能提交一次請求。

3. 「下單」的URL在活動開始前不可露出或者生效,不然容易被使用工具繞過瀏覽器提早下單。致使活動還未開始,已經開始下單這個大黑洞。正確的作法是活動開始前,經過更新JS文件露出下單的URL。

4. 下單過程當中,涉及到訂單參數的修改所有關掉,好比,購買的金額,產品的份額等等,下降訂單服務的壓力。



2. 服務層的設計


服務層的設計,以下圖所示:



  1. 確保全部服務的緩存是獨立分開,相互不影響。

  2. 按照昨天文章寫到的那樣,檢查用戶的身份和條件,將無效的用戶請求阻止在業務層以前。

  3. 全部讀請求所有走緩存,Redis or MemCached, 也能夠考慮走讀庫,請注意流量的分配。

  4. 秒殺開始前,全部產品的屬性和庫存預加載到緩存中,秒殺過程當中不主動更新數據庫,庫存數據延遲異步更新。

  5. 對於訂單的寫請求,加緩存,並作請求隊列,每次只透過有限的寫請求去數據層,扣除庫存成功均成功再進行下一批訂單數據的更新,若是庫存不夠則隊列裏的寫請求所有直接返回,儘量阻止無效的請求穿透到數據層;

  6. 當瞬間秒殺產品庫存太大,形成的Redis寫暴增,可能形成線程阻塞最後寫超時對於如上的異常,添加一個秒殺開關,大量異常時開關關閉中止一切秒殺活動,以避免形成更大的損失。


創建秒殺系統的監


爲了應對秒殺過程當中的各類突發狀況,咱們還須要創建有效的監控手段來保障秒殺的過程。


  1. 監控Redis調用性能,主要是看讀和寫的性能兩個指標。

  2. 監控各個關鍵接口的運行狀況,特別是下單接口的狀態,看是否有大量請求timeout或者異常的狀況出現,關注失敗的訂單數,設置預警閾值。若是超過閾值,報警並採起緊急處理措施,例如關閉秒殺,進行服務降級。

  3. 監控數據庫的性能,密切關注訂單寫庫的執行狀態和讀庫的同步狀況。



掃描二維碼或手動搜索微信公衆號【架構棧】: ForestNotes

歡迎轉載,帶上如下二維碼便可

相關文章
相關標籤/搜索