大家好，我是濤哥。
一年前，在寫技術公眾號初期，我寫了一篇關於秒殺系統設計的文章，被各大小公眾號轉載了30多次。文章字數不多，通俗易懂，備受讀者好評。今天將這篇文章重新發一次，希望被更多的讀者看到，以期對大家有所幫助。
本文3000字，閱讀時間10分鍾。
個人從事電商行業十幾年，經歷過大大小小的促銷活動和秒殺上百次，每次做秒殺瞬時訪問量會翻數十倍，甚至數百倍。對系統架構是巨大的考驗，期間也曾經歷過系統宕機，甚至整體雪崩。那么我們怎么設計秒殺系統，才能保證秒殺系統的高性能和穩定性，同時還要保證日常業務不受影響呢？
先看看秒殺場景特點。秒殺開始前幾分鍾，大量用戶開始進入秒殺商品詳情頁面，很多人開始頻繁刷新秒殺商品詳情頁，這時秒殺商品詳情頁訪問量會猛增。秒殺開始，大量用戶開始搶購，這時創建訂單，扣庫存壓力會顯著增大。實際上，秒殺場景基本都是秒殺參與人多，秒殺成功的人卻寥寥無幾，經常是幾十萬人或者更多人搶幾百個商品庫存。
那么我們曾經是怎么設計秒殺系統的呢？主要涉及以下幾個方面：
秒殺業務流程上的考慮
由於參加秒殺的商品售賣價格非常低，基本都是“搶到即賺到”，成功下單后卻不付款的情況非常少。所以我們采用下單減庫存的方案，下單時扣減庫存，然后再進行支付。假如真有個別訂單不付款怎么辦？沒關系，秒殺好活動最主要的目的是吸引流量，個別訂單不支付對秒殺活動本身影響不大。況且，沒支付剩下的庫存還可以做為普通商品繼續售賣。不過要注意對機器人和自動腳本的防御，后面會詳細介紹。
頁面靜態化
“秒殺開始前幾分鍾，大量用戶開始進入秒殺商品詳情頁面，很多人開始頻繁刷新秒殺商品詳情頁，這時秒殺商品詳情頁訪問量會猛增”。如果請求全部打到后端服務，那后端服務的壓力會非常大（后端服務要處理業務邏輯，而且還要訪問數據庫，吞吐量比較低）。
考慮到秒殺是運營同學提前安排的活動，要秒殺哪些商品、商品價格等信息在秒殺活動開始前已經確定下來，所以我們可以把秒殺商品詳情頁做成靜態頁面，把商品詳情、商品價格等參數、評論評價等信息全部放在這個靜態頁面里，然后把這個靜態頁面上傳到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服務商提前申請帶寬。
還有哪些細節要考慮
-
如何避免超賣？如果在redis中扣減庫存，可以利用decr命令扣減庫存，decr是原子操作，在分布式環境下也不會有並發問題，decr扣減庫存后，判斷返回值，如果返回值小於0，扣減庫存失敗，秒殺也就失敗了；如果在數據庫中扣減庫存可以在where后面加上庫存大於0的條件，來避免庫存被減成負值。這樣就可以避免超賣情況發生了。
-
接口防刷，前面已經提到過，在網關層對下單等接口按userID限流。
-
網關層除了對userID做限流外，還要做整體限流。在實際訪問量超過預估訪問量時，整體限流可以起到保護作用，避免系統被壓垮。
-
防止重復下單，按userID限流已經起到了防止重復下單的作用。假如限制同一個用戶10分鍾能下一次單，一般情況下10分鍾內，商品早已經被搶光了，用戶也就沒有再次下單的機會了。
-
可以結合風控系統，在網關層把羊毛黨等有問題的用戶請求直接拒掉。
-
可以在網關層上面再加一層防火牆或者高防服務，來防御DDos等分布式網絡攻擊。
好啦，就分享到這里。如果感覺本文對你有幫助，有勞動動手指轉發一下，分享是美德哦。
本文完，請大家繼續關注濤哥后續的技術原創！
作者簡介：曾任職於阿里巴巴，每日優鮮等互聯網公司，任技術總監，15年電商互聯網經歷。