前言
最近在部門內部分享了原來在電商業務做秒殺活動的整體思路，大家對這次分享反饋還不錯，所以我就簡單整理了一下，分享給大家參考參考。
業務介紹
什麼是秒殺？通俗一點講就是網路商家為**等目的組織的網上限時搶購活動。
比如說京東秒殺，就是一種定時定量秒殺，在規定的時間內，無論商品是否秒殺完畢，該場次的秒殺活動都會結束。這種秒殺，對時間不是特別嚴格，只要下手快點，秒中的概率還是比較大的。
**以前就做過一元搶購，一般都是限量 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 排隊服務頂住，後面下訂單與扣減庫存的壓力都是自己能控制的，根據資料庫的壓力，可以定製化建立訂單消費者的數量，避免出現消費者資料量過多，導致資料庫壓力過大或者直接宕機。
庫存服務專門為秒殺的商品提供庫存管理，實現提前鎖定庫存，避免超賣的現象。同時，通過超時處理任務發現已搶到商品，但未付款的訂單，並在規定付款時間後，處理這些訂單，將恢復訂單商品對應的庫存量。
總結核心思想：層層過濾
盡量將請求攔截在上游，降低下游的壓力
充分利用快取與訊息佇列，提高請求處理速度以及削峰填谷的作用
參考秒殺業務架構優化之路
網際網路秒殺業務設計
高併發秒殺系統架構設計
如何設計乙個秒殺系統
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...
如何設計乙個秒殺系統
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...
如何設計乙個秒殺系統
秒殺一般是訪問請求數量遠遠大於庫存數量，只有少部分使用者能夠秒殺成功。秒殺業務流程比較簡單，一般就是下訂單減庫存。瀏覽器端 js 服務端控制器層 閘道器層 服務層利用快取應對讀請求 對類似於12306等購票業務，是典型的讀多寫少業務，大部分請求是查詢請求，所以可以利用快取分擔資料庫壓力。利用快取應對...