前言
最近在部門内部分享了原來在電商業務做秒殺活動的整體思路，大家對這次分享回報還不錯，是以我就簡單整理了一下，分享給大家參考參考
業務介紹
什麼是秒殺？通俗一點講就是網絡商家為促銷等目的組織的網上限時搶購活動
比如說京東秒殺，就是一種定時定量秒殺，在規定的時間内，無論商品是否秒殺完畢，該場次的秒殺活動都會結束。這種秒殺，對時間不是特别嚴格，隻要下手快點，秒中的機率還是比較大的。
淘寶以前就做過一進制搶購，一般都是限量 1 件商品，同時價格低到「令人發齒」，這種秒殺一般都在開始時間 1 到 3 秒内就已經搶光了，參與這個秒殺一般都是看運氣的，不必太強求
業務特點
瞬時并發量大
秒殺時會有大量使用者在同一時間進行搶購，瞬時并發通路量突增 10 倍，甚至 100 倍以上都有。
庫存量少
一般秒殺活動商品量很少，這就導緻了隻有極少量使用者能成功購買到。
業務簡單
流程比較簡單，一般都是下訂單、扣庫存、支付訂單
技術難點
現有業務的沖擊
秒殺是營銷活動中的一種，如果和其他營銷活動應用部署在同一伺服器上，肯定會對現有其他活動造成沖擊，極端情況下可能導緻整個電商系統服務當機
直接下訂單
下單頁面是一個正常的 URL 位址，需要控制在秒殺開始前，不能下訂單，隻能浏覽對應活動商品的資訊。簡單來說，需要 Disable 訂單按鈕
頁面流量突增
秒殺活動開始前後，會有很多使用者請求對應商品頁面，會造成背景伺服器的流量突增，同時對應的網絡帶寬增加，需要控制商品頁面的流量不會對背景伺服器、DB、Redis 等元件的造成過大的壓力
架構設計思想
限流
由于活動庫存量一般都是很少，對應的隻有少部分使用者才能秒殺成功。是以我們需要限制大部分使用者流量，隻準少量使用者流量進入後端伺服器
削峰
秒殺開始的那一瞬間，會有大量使用者沖擊進來，是以在開始時候會有一個瞬間流量峰值。如何把瞬間的流量峰值變得更平緩，是能否成功設計好秒殺系統的關鍵因素。實作流量削峰填谷，一般的采用緩存和 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 排隊服務頂住，後面下訂單與扣減庫存的壓力都是自己能控制的，根據資料庫的壓力，可以定制化建立訂單消費者的數量，避免出現消費者資料量過多，導緻資料庫壓力過大或者直接當機。
總結
-
- 盡量将請求攔截在上遊，降低下遊的壓力
- 充分利用緩存與消息隊列，提高請求處理速度以及削峰填谷的作用