秒殺，這是我見過最最實用的技術方案

大家好，我是濤哥。

一年前，在寫技術公衆號初期，我寫了一篇關於秒殺系統設計的文章，被各大小公衆號轉載了 30 多次。文章字數不多，通俗易懂，備受讀者好評。今天將這篇文章重新發一次，希望被更多的讀者看到，以期對大家有所幫助。

個人從事電商行業十幾年，經歷過大大小小的促銷活動和秒殺上百次，每次做秒殺瞬時訪問量會翻數十倍，甚至數百倍。對系統架構是巨大的考驗，期間也曾經歷過系統宕機，甚至整體雪崩。那麼我們怎麼設計秒殺系統，才能保證秒殺系統的高性能和穩定性，同時還要保證日常業務不受影響呢？

先看看秒殺場景特點。秒殺開始前幾分鐘，大量用戶開始進入秒殺商品詳情頁面，很多人開始頻繁刷新秒殺商品詳情頁，這時秒殺商品詳情頁訪問量會猛增。秒殺開始，大量用戶開始搶購，這時創建訂單，扣庫存壓力會顯著增大。實際上，秒殺場景基本都是秒殺參與人多，秒殺成功的人卻寥寥無幾，經常是幾十萬人或者更多人搶幾百個商品庫存。

那麼我們曾經是怎麼設計秒殺系統的呢？主要涉及以下幾個方面：

秒殺業務流程上的考慮

由於參加秒殺的商品售賣價格非常低，基本都是 “搶到即賺到”，成功下單後卻不付款的情況非常少。所以我們採用下單減庫存的方案，下單時扣減庫存，然後再進行支付。假如真有個別訂單不付款怎麼辦？沒關係，秒殺好活動最主要的目的是吸引流量，個別訂單不支付對秒殺活動本身影響不大。況且，沒支付剩下的庫存還可以做爲普通商品繼續售賣。不過要注意對機器人和自動腳本的防禦，後面會詳細介紹。

頁面靜態化

“秒殺開始前幾分鐘，大量用戶開始進入秒殺商品詳情頁面，很多人開始頻繁刷新秒殺商品詳情頁，這時秒殺商品詳情頁訪問量會猛增”。如果請求全部打到後端服務，那後端服務的壓力會非常大（後端服務要處理業務邏輯，而且還要訪問數據庫，吞吐量比較低）。

考慮到秒殺是運營同學提前安排的活動，要秒殺哪些商品、商品價格等信息在秒殺活動開始前已經確定下來，所以我們可以把秒殺商品詳情頁做成靜態頁面，把商品詳情、商品價格等參數、評論評價等信息全部放在這個靜態頁面裏，然後把這個靜態頁面上傳到 CDN 上預熱（CDN 是內容分發網絡，可以簡單理解成互聯網上的巨大的緩存，用於存放靜態頁面、圖片、視頻等，可以顯著提高訪問速度），用 CDN 扛流量，這樣大量的商品詳情頁的訪問請求就不用訪問自己的網站（源站）。這樣既可以提高訪問速度，也沒有給網站增加壓力，同時也減少了網站帶寬壓力。

請求攔截

前端頁面，相關按鈕點擊後置灰，防止重複提交

網關（zuul，nginx）層，爲了避免前端惡意請求，比如一些攻擊腳本，在網關層要對下單等接口按 userID 限流，幾秒鐘只能訪問一次。考慮到秒殺場景參與人多，秒殺成功的人極少，我們可以把絕大部分搶購下單請求在網關層直接拒掉，按秒殺失敗處理。這樣就極大減少了後端服務的壓力。

假設秒殺庫存是 200 個，我們可以只放行 200 個請求到後端服務。要注意，爲了儘量避免庫存被機器人和自動腳本搶走，200 個請求不能在秒殺開始瞬間同時放行，可以分段放行，比如秒殺開始後隨機選取 100ms 內的 10 個請求放行（這 100ms 內的其他請求直接拒掉，按秒殺失敗處理），之後每隔 100ms 放行 10 個請求，2 秒鐘可以放行完 200 個請求。分段放行，除了限制了機器人和自動腳本，把請求分散在各個時間段，還進一步緩解了後端服務的壓力。

分段放行總時間不能太長，假如每 100ms 放行 1 個請求，放行完所有 200 個請求需要 20 秒時間，這樣用戶就會明顯感知到下單早的人沒秒殺成功，下單晚的人反而秒殺成功了，用戶體驗會變差。

另外，秒殺過程網關壓力會比較大，網關可以做成集羣，多節點分攤訪問壓力。

後端服務設計

如果秒殺庫存只有 200，經過網關攔截，再加上採用分段放行的方式，對於後端服務基本沒什麼壓力了，日常的後端服務就完全可以支撐秒殺活動了。不用再做更復雜的設計。不過，假如秒殺庫存有幾萬個，放行的下單請求就有幾萬個，爲了用戶體驗放行總時間也不能太長，這時後端服務該怎麼設計呢？

這時主要壓力就在數據庫了，扣減庫存壓力，創建訂單壓力。

庫存可以放到 Reids 緩存中，來提高扣減庫存吞吐能力。對於熱點商品的庫存可以利用 Redis 分片存儲。

創建訂單可以走異步消息隊列。後端服務接到下單請求，直接放進消息隊列，監聽服務取出消息後，先將訂單信息寫入 Redis，每隔 100ms 或者積攢 100 條訂單，批量寫入數據庫一次。前端頁面下單後定時向後端拉取訂單信息，獲取到訂單信息後跳轉到支付頁面。用這種批量異步寫入數據庫的方式大幅減少了數據庫寫入頻次，從而明顯降低了訂單數據庫寫入壓力。

隔離

1，業務隔離。從業務上把秒殺和日常的售賣區分開來，把秒殺做爲營銷活動，要參與秒殺的商品需要提前報名參加活動，這樣我們就能提前知道哪些商家哪些商品要參與秒殺，可以根據提報的商品提前生成靜態頁面並上傳到 CDN 預熱，提報的商品庫存也需要提前預熱，可以將商品庫存在活動開始前預熱到 Redis，避免秒殺開始後大量的緩存穿透。

2，部署隔離。秒殺相關服務和日常服務要分組部署，不能因爲秒殺出問題影響日常售賣業務。可以申請單獨的秒殺域名，從網絡入口層就開始分流。網關也單獨部署，秒殺走自己單獨的網關，從而避免日常網關受到影響。秒殺可以複用訂單，庫存，支付等日常服務，只是需要一些小的改造（比如下單流程走消息隊列，批量寫入訂單庫，以及在 Redis 中扣減庫存）。

3，數據隔離。爲了避免秒殺活動影響到日常售賣業務，Redis 緩存需要單獨部署，甚至數據庫也需要單獨部署！數據隔離後，秒殺剩餘的庫存怎麼辦？秒殺活動結束後，剩餘庫存可以歸還到日常庫存繼續做爲普通商品售賣。數據隔離後，秒殺訂單和日常訂單不在相同的數據庫，之後的訂單查詢怎麼展示？可以在創建秒殺訂單後發消息到消息隊列，日常訂單服務採取拉的方式消費消息，這時日常訂單服務是主動方，可以採用線程池的方式，根據機器的性能來增加或縮小線程池的大小，控制拉取消息的速度，來控制訂單數據庫的寫入壓力。

網絡

秒殺前要和網絡運營商、CDN 服務商提前申請帶寬。

還有哪些細節要考慮

1. 如何避免超賣？如果在 redis 中扣減庫存，可以利用 decr 命令扣減庫存，decr 是原子操作，在分佈式環境下也不會有併發問題，decr 扣減庫存後，判斷返回值，如果返回值小於 0，扣減庫存失敗，秒殺也就失敗了；如果在數據庫中扣減庫存可以在 where 後面加上庫存大於 0 的條件，來避免庫存被減成負值。這樣就可以避免超賣情況發生了。

2. 接口防刷，前面已經提到過，在網關層對下單等接口按 userID 限流。

3. 網關層除了對 userID 做限流外，還要做整體限流。在實際訪問量超過預估訪問量時，整體限流可以起到保護作用，避免系統被壓垮。

4. 防止重複下單，按 userID 限流已經起到了防止重複下單的作用。假如限制同一個用戶 10 分鐘能下一次單，一般情況下 10 分鐘內，商品早已經被搶光了，用戶也就沒有再次下單的機會了。

5. 可以結合風控系統，在網關層把羊毛黨等有問題的用戶請求直接拒掉。

6. 可以在網關層上面再加一層防火牆或者高防服務，來防禦 DDos 等分佈式網絡攻擊。

好啦，就分享到這裏。如果感覺本文對你有幫助，有勞動動手指轉發一下，分享是美德哦。

本文完，請大家繼續關注濤哥後續的技術原創！

作者簡介：曾任職於阿里巴巴，每日優鮮等互聯網公司，任技術總監，15 年電商互聯網經歷。

更多幹貨請關注微信公衆號：二馬讀書

歡迎留言，和濤哥在線交流

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/UwtsQLBgBMvDlC0SljHmeQ