淘寶雙十一電商秒殺系統架構設計

前言

最近在部門內部分享了原來在電商業務作秒殺活動的總體思路，你們對此次分享反饋還不錯，因此我就簡單整理了一下，分享給你們參考參考

業務介紹

什麼是秒殺？通俗一點講就是網絡商家爲促銷等目的組織的網上限時搶購活動

好比說京東秒殺，就是一種定時定量秒殺，在規定的時間內，不管商品是否秒殺完畢，該場次的秒殺活動都會結束。這種秒殺，對時間不是特別嚴格，只要下手快點，秒中的機率仍是比較大的。

淘寶之前就作過一元搶購，通常都是限量 1 件商品，同時價格低到「使人發齒」，這種秒殺通常都在開始時間 1 到 3 秒內就已經搶光了，參與這個秒殺通常都是看運氣的，沒必要太強求

業務特色

瞬時併發量大

秒殺時會有大量用戶在同一時間進行搶購，瞬時併發訪問量突增 10 倍，甚至 100 倍以上都有。

庫存量少

通常秒殺活動商品量不多，這就致使了只有極少許用戶能成功購買到。

業務簡單

流程比較簡單，通常都是下訂單、扣庫存、支付訂單

技術難點

現有業務的衝擊

秒殺是營銷活動中的一種，若是和其餘營銷活動應用部署在同一服務器上，確定會對現有其餘活動形成衝擊，極端狀況下可能致使整個電商系統服務宕機

直接下訂單

下單頁面是一個正常的 URL 地址，須要控制在秒殺開始前，不能下訂單，只能瀏覽對應活動商品的信息。簡單來講，須要 Disable 訂單按鈕

頁面流量突增

秒殺活動開始先後，會有不少用戶請求對應商品頁面，會形成後臺服務器的流量突增，同時對應的網絡帶寬增長，須要控制商品頁面的流量不會對後臺服務器、DB、Redis 等組件的形成過大的壓力

在此我向你們推薦一個架構學習交流羣。交流學習羣號：736220120  裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多。

架構設計思想

限流

因爲活動庫存量通常都是不多，對應的只有少部分用戶才能秒殺成功。因此咱們須要限制大部分用戶流量，只准少許用戶流量進入後端服務器

削峯

秒殺開始的那一瞬間，會有大量用戶衝擊進來，因此在開始時候會有一個瞬間流量峯值。如何把瞬間的流量峯值變得更平緩，是可否成功設計好秒殺系統的關鍵因素。實現流量削峯填谷，通常的採用緩存和 MQ 中間件來解決

異步

秒殺其實能夠當作高併發系統來處理，在這個時候，能夠考慮從業務上作兼容，將同步的業務，設計成異步處理的任務，提升網站的總體可用性

緩存

秒殺系統的瓶頸主要體如今下訂單、扣減庫存流程中。在這些流程中主要用到 OLTP 的數據庫，相似 MySQL、SQLServer、Oracle。因爲數據庫底層採用 B+ 樹的儲存結構，對應咱們隨機寫入與讀取的效率，相對較低。若是咱們把部分業務邏輯遷移到內存的緩存或者 Redis 中，會極大的提升併發效率

總體架構

客戶端優化

客戶端優化主要有兩個問題

秒殺頁面

秒殺活動開始前，其實就有不少用戶訪問該頁面了。若是這個頁面的一些資源，好比 CSS、JS、圖片、商品詳情等，都訪問後端服務器，甚至 DB 的話，服務確定會出現不可用的狀況。因此通常咱們會把這個頁面總體進行靜態化，並將頁面靜態化以後的頁面分發到 CDN 邊緣節點上，起到壓力分散的做用

防止提早下單

防止提早下單主要是在靜態化頁面中加入一個 JS 文件引用，該 JS 文件包含活動是否開始的標記以及開始時的動態下單頁面的 URL 參數。同時，這個 JS 文件是不會被 CDN 系統緩存的，會一直請求後端服務的，因此這個 JS 文件必定要很小。當活動快開始的時候（好比提早），經過後臺接口修改這個 JS 文件使之生效

API 接入層優化

客戶端優化，對於不是搞計算機方面的用戶仍是能夠防止住的。可是稍有必定網絡基礎的用戶就起不到做用了，所以服務端也須要加些對應控制，不能信任客戶端的任何操做。通常控制分爲 2 大類

限制用戶維度訪問頻率

針對同一個用戶（ Userid 維度），作頁面級別緩存，單元時間內的請求，統一走緩存，返回同一個頁面

限制商品維度訪問頻率

大量請求同時間段查詢同一個商品時，能夠作頁面級別緩存，無論下回是誰來訪問，只要是這個頁面就直接返回

SOA 服務層優化

上面兩層只能限制異經常使用戶訪問，若是秒殺活動運營的比較好，不少用戶都參加了，就會形成系統壓力過大甚至宕機，所以須要後端流量控制

對於後端系統的控制能夠經過消息隊列、異步處理、提升併發等方式解決。對於超過系統水位線的請求，直接採起 「Fail-Fast」原則，拒絕掉

秒殺總體流程圖

秒殺系統核心在於層層過濾，逐漸遞減瞬時訪問壓力，減小最終對數據庫的衝擊。經過上面流程圖就會發現壓力最大的地方在哪裏？

MQ 排隊服務，只要 MQ 排隊服務頂住，後面下訂單與扣減庫存的壓力都是本身能控制的，根據數據庫的壓力，能夠定製化建立訂單消費者的數量，避免出現消費者數據量過多，致使數據庫壓力過大或者直接宕機。

庫存服務專門爲秒殺的商品提供庫存管理，實現提早鎖定庫存，避免超賣的現象。同時，經過超時處理任務發現已搶到商品，但未付款的訂單，並在規定付款時間後，處理這些訂單，將恢復訂單商品對應的庫存量

 

總結

核心思想：層層過濾

儘可能將請求攔截在上游，下降下游的壓力

充分利用緩存與消息隊列，提升請求處理速度以及削峯填谷的做用