背景

我之前寫過一個秒殺系統的文章不過有些許瑕疵，所以我準備在之前的基礎上進行二次創作，不過讓我決心二創秒殺系統的原因是我最近面試了很多讀者，動不動就是秒殺系統把我整蒙蔽了，我懵的主要是秒殺系統的細節大家都不知道，甚至不知道電商公司一個秒殺系統的組成部分。

我之前在某電商公司就是做電商活動的，所以這樣的場景和很多解決方案我是比較清楚的，那我就從我自身去帶著大家看看一個秒殺的設計細節以及中間各種解決方案的利弊，以下就是我設計的秒殺系統，幾乎涵蓋了市面上所有秒殺的實現細節：

正文

首先設計一個系統之前，我們需要先確認我們的業務場景是怎么樣子的，我就帶著大家一起假設一個場景好吧。

我們現場要賣1000件下面這個嬰兒紙尿褲，然后我們根據以往這樣秒殺活動的數據經驗來看，目測來搶這100件紙尿褲的人足足有10萬人。（南極人打錢！）

你一聽，完了呀，這我們的服務器哪里頂得住啊！說真的直接打DB肯定掛，但是別急嘛，有暖男敖丙在，任何系統我們開始設計之前我們都應該去思考會出現哪些問題？這里我羅列了幾個非常經典的問題：

問題

高并發：

是的高并發這個是我們想都不用想的一個點，一瞬間這么多人進來這不是高并發什么時候是呢？

是吧，秒殺的特點就是這樣時間極短、 瞬間用戶量大。

正常的店鋪營銷都是用極低的價格配合上短信、APP的精準推送，吸引特別多的用戶來參與這場秒殺，爽了商家苦了開發呀。

秒殺大家都知道如果真的營銷到位，價格誘人，幾十萬的流量我覺得完全不是問題，那單機的Redis我感覺3-4W的QPS還是能頂得住的，但是再高了就沒辦法了，那這個數據隨便搞個熱銷商品的秒殺可能都不止了。

大量的請求進來，我們需要考慮的點就很多了，緩存雪崩，緩存擊穿，緩存穿透這些我之前提到的點都是有可能發生的，出現問題打掛DB那就很難受了，活動失敗用戶體驗差，活動人氣沒了，最后背鍋的還是開發。

超賣：

但凡是個秒殺，都怕超賣，我這里舉例的只是尿不濕，要是換成100個MacBook Pro，商家的預算經費賣100個可以賺點還可以造勢，結果你寫錯程序多賣出去200個，你不發貨用戶投訴你，平臺封你店，你發貨就血虧，你怎么辦？ （沒事看了敖丙的文章直接不怕）

那最后只能殺個開發祭天解氣了，秒殺的價格本來就低了，基本上都是不怎么賺錢的，超賣了就恐怖了呀，所以超賣也是很關鍵的一個點。

惡意請求：

你這么低的價格，假如我搶到了，我轉手賣掉我不是血賺？就算我不賣我也不虧啊，那用戶知道，你知道，別的別有用心的人（黑客、黃牛...）肯定也知道的。

那簡單啊，我知道你什么時候搶，我搞個幾十臺機器搞點腳本，我也模擬出來十幾萬個人左右的請求，那我是不是意味著我基本上有80%的成功率了。

真實情況可能遠遠不止，因為機器請求的速度比人的手速往往快太多了，在貴州的敖丙我每年回家搶高鐵票都是秒光的，我也不知道有沒有黃牛的功勞，我要Diss你，黃牛。杰倫演唱會門票搶不到，我也Diss你。

Tip：科普下，小道消息了解到的，黃牛的搶票系統，比國內很多小公司的系統還吊很多，架構設計都是頂級的，我用頂配的服務加上頂配的架構設計，你還想看演唱會？還想回家？

不過不用黃牛我回家都難，我們云貴川跟我一樣要回家過年的仔太多了555！

鏈接暴露：

前面幾個問題大家可能都很好理解，一看到這個有的小伙伴可能會比較疑惑，啥是鏈接暴露呀？

相信是個開發同學都對這個畫面一點都不陌生吧，懂點行的仔都可以打開谷歌的開發者模式，然后看看你的網頁代碼，有的就有URL，但是我寫VUE的時候是事件觸發然后去調用文件里面的接口看源碼看不到，但是我可以點擊一下查看你的請求地址啊，不過你好像可以對按鈕在秒殺前置灰。

不管怎么樣子都有危險，撇開外面的所有的東西你都擋住了，你賣這個東西實在便宜得過分，有誘惑力，你能保證開發不動心？開發知道地址，在秒殺的時候自己提前請求。。。（開發：怎么TM又是我）

數據庫：

每秒上萬甚至十幾萬的QPS（每秒請求數）直接打到數據庫，基本上都要把庫打掛掉，而且你服務不單單是做秒殺的還涉及其他的業務，你沒做降級、限流、熔斷啥的，別的一起掛，小公司的話可能全站崩潰404。

反正不管你秒殺怎么掛，你別把別的搞掛了對吧，搞掛了就不是殺一個程序員能搞定的。

程序員：我TM好難啊！

問題都列出來了，那怎么設計，怎么解決這些問題就是接下去要考慮的了，我們對癥下藥。

我會從我設計的秒殺系統從上到下去給大家介紹我們正常電商秒殺系統在每一層做了些什么，每一層存在的問題，難點等。

我們從前端開始：

前端

秒殺系統普遍都是商城網頁、H5、APP、小程序這幾項。

在前端這一層其實我們可以做的事情有很多，如果用node去做，甚至能直接處理掉整個秒殺，但是node其實應該屬于后端，所以我不討論node Service了。

資源靜態化：

秒殺一般都是特定的商品還有頁面模板，現在一般都是前后端分離的，頁面一般都是不會經過后端的，但是前端也要自己的服務器啊，那就把能提前放入cdn服務器的東西都放進去，反正把所有能提升效率的步驟都做一下，減少真正秒殺時候服務器的壓力。

秒殺鏈接加鹽：

我們上面說了鏈接要是提前暴露出去可能有人直接訪問url就提前秒殺了，那又有小伙伴要說了我做個時間的校驗就好了呀，那我告訴你，知道鏈接的地址比起頁面人工點擊的還是有很大優勢。

我知道url了，那我通過程序不斷獲取最新的北京時間，可以達到毫秒級別的，我就在00毫秒的時候請求，我敢說絕對比你人工點的成功率大太多了，而且我可以一毫秒發送N次請求，搞不好你賣100個產品我全拿了。

那這種情況怎么避免？

簡單，把URL動態化，就連寫代碼的人都不知道，你就通過MD5之類的摘要算法加密隨機的字符串去做url，然后通過前端代碼獲取url后臺校驗才能通過。

這個只能防止一部分沒耐心繼續破解下去的黑客，有耐心的人研究出來還是能破解，在電商場景存在很多這樣的羊毛黨，那怎么做呢？

后面我會說。

限流：

限流這里我覺得應該分為前端限流和后端限流。

物理控制：

大家有沒有發現沒到秒殺前，一般按鈕都是置灰的，只有時間到了，才能點擊。

這是因為怕大家在時間快到的最后幾秒秒瘋狂請求服務器，然后還沒到秒殺的時候基本上服務器就掛了。

這個時候就需要前端的配合，定時去請求你的后端服務器，獲取最新的北京時間，到時間點再給按鈕可用狀態。

按鈕可以點擊之后也得給他置灰幾秒，不然他一樣在開始之后一直點的。

你敢說你們秒殺的時候不是這樣的？

前端限流：這個很簡單，一般秒殺不會讓你一直點的，一般都是點擊一下或者兩下然后幾秒之后才可以繼續點擊，這也是保護服務器的一種手段。

后端限流：秒殺的時候肯定是涉及到后續的訂單生成和支付等操作，但是都只是成功的幸運兒才會走到那一步，那一旦100個產品賣光了，return了一個false，前端直接秒殺結束，然后你后端也關閉后續無效請求的介入了。

Tip：真正的限流還會有限流組件的加入例如：阿里的Sentinel、Hystrix等。我這里就不展開了，就說一下物理的限流。

我們賣1000件商品，請求有10W，我們不需要把十萬都放進來，你可以放1W請求進來，然后再進行操作，因為秒殺對于用戶本身就是黑盒的，所以你怎么做的他們是沒感知的，至于為啥放1W進來，而不是剛好1000，是因為會丟掉一些薅羊毛的用戶，至于怎么判斷，后面的風控階段我會說。

Nginx：

Nginx大家想必都不陌生了吧，這玩意是高性能的web服務器，并發也隨便頂幾萬不是夢，但是我們的Tomcat只能頂幾百的并發呀，那簡單呀負載均衡嘛，一臺服務幾百，那就多搞點，在秒殺的時候多租點流量機。

Tip：據我所知國內某大廠就是在去年春節活動期間租光了亞洲所有的服務器，小公司也很喜歡在雙十一期間買流量機來頂住壓力。

這樣一對比是不是覺得你的集群能頂很多了。

惡意請求攔截也需要用到它，一般單個用戶請求次數太夸張，不像人為的請求在網關那一層就得攔截掉了，不然請求多了他搶不搶得到是一回事，服務器壓力上去了，可能占用網絡帶寬或者把服務器打崩、緩存擊穿等等。

風控

我可以明確的告訴大家，前面的所有措施還是攔不住很多羊毛黨，因為他們是專業的團隊，他們可以注冊很多賬號來薅你的羊毛，而且不用機器請求，就用群控，操作幾乎跟真實用戶一模一樣。

那怎么辦，是不是無解了？

這個時候就需要風控同學的介入了，在請求到達后端之前，風控可以根據賬號行為分析出這個賬號機器人的概率大不大，我現在負責公司的某些特殊系統，每個用戶的行為都是會送到我們大數據團隊進行分析處理，給你打上對應標簽的。

那黑客其實也有辦法：養號

他們去黑市買真實用戶有過很多記錄的賬號，買到了還不閑著，幫他們去購物啥的，讓系統無法識別他們是黑號還是真實用戶的號。

怎么辦？

通殺！是的沒有辦法，只能通殺了，通殺的意思就是，我們通過風管分析出來這個用戶是真實用戶的概率沒有其他用戶概率大，那就認為他是機器了，丟棄他的請求。

之前的限流我們放進來10000個請求，但是我們真正的庫存只有1000個，那我們就算出最有可能是真實用戶的1000人進行秒殺，丟棄其他請求，因為秒殺本來就是黑盒操作的，用戶層面是無感知的，這樣設計能讓真實的用戶買到東西，還可以減少自己被薅羊毛的概率。

風控可以說是流量進入的最后一道門檻了，所以很多公司的風控是很強的，螞蟻金服的風控大家如果了解過就知道了，你的資金在支付寶被盜了，他們是能做到全款補償是有原因的。

后端

服務單一職責：

設計個能抗住高并發的系統，我覺得還是得單一職責。

什么意思呢，大家都知道現在設計都是微服務的設計思想，然后再用分布式的部署方式。

也就是我們下單是有個訂單服務，用戶登錄管理等有個用戶服務等等，那為啥我們不給秒殺也開個服務，我們把秒殺的代碼業務邏輯放一起。

單一職責的好處就是就算秒殺沒抗住，秒殺庫崩了，服務掛了，也不會影響到其他的服務。（高可用）

Redis集群：

之前不是說單機的Redis頂不住嘛，那簡單多找幾個兄弟啊，秒殺本來就是讀多寫少，那你們是不是瞬間想起來我之前跟你們提到過的，Redis集群，主從同步、讀寫分離，我們還搞點哨兵，開啟持久化直接無敵高可用！

庫存預熱：

秒殺的本質，就是對庫存的搶奪，每個秒殺的用戶來你都去數據庫查詢庫存校驗庫存，然后扣減庫存，撇開性能因數，你不覺得這樣好繁瑣，對業務開發人員都不友好，而且數據庫頂不住啊。

開發：你tm總算為我著想一次了。

那怎么辦？

我們都知道數據庫頂不住但是他的兄弟非關系型的數據庫Redis能頂啊！

那不簡單了，我們要開始秒殺前你通過定時任務或者運維同學提前把商品的庫存加載到Redis中去，讓整個流程都在Redis里面去做，然后等秒殺介紹了，再異步的去修改庫存就好了。

但是用了Redis就有一個問題了，我們上面說了我們采用主從，就是我們會去讀取庫存然后再判斷然后有庫存才去減庫存，正常情況沒問題，但是高并發的情況問題就很大了。

**多品幾遍！！！**就比如現在庫存只剩下1個了，我們高并發嘛，4個服務器一起查詢了發現都是還有1個，那大家都覺得是自己搶到了，就都去扣庫存，那結果就變成了-3，是的只有一個是真的搶到了，別的都是超賣的。咋辦？

事務：

Redis本身是支持事務的，而且他有很多原子命令的，大家也可以用LUA，還可以用他的管道，樂觀鎖他也知支持。

限流&降級&熔斷&隔離：

這個為啥要做呢，不怕一萬就怕萬一，萬一你真的頂不住了，限流，頂不住就擋一部分出去但是不能說不行，降級，降級了還是被打掛了，熔斷，至少不要影響別的系統，隔離，你本身就獨立的，但是你會調用其他的系統嘛，你快不行了你別拖累兄弟們啊。

消息隊列（削峰填谷）：

一說到這個名詞，很多小伙伴就知道了，對的MQ，你買東西少了你直接100個請求改庫我覺得沒問題，但是萬一秒殺一萬個，10萬個呢？服務器掛了，程序員又要背鍋的。

秒殺就是這種瞬間流量很高，但是平時又沒有流量的場景，那消息隊列完全契合這樣的場景了呀，削峰填谷。

Tip：可能小伙伴說我們業務達不到這個量級，沒必要。但是我想說我們寫代碼，就不應該寫出有邏輯漏洞的代碼，至少以后公司體量上去了，別人一看居然不用改代碼，一看代碼作者是敖丙？有點東西！

你可以把它放消息隊列，然后一點點消費去改庫存就好了嘛，不過單個商品其實一次修改就夠了，我這里說的是某個點多個商品一起秒殺的場景，像極了雙十一零點。

數據庫

數據庫用MySQL只要連接池設置合理一般問題是不大的，不過一般大公司不缺錢而且秒殺這樣的活動十分頻繁，我之前所在的公司就是這樣秒殺特賣這樣的場景一直都是不間斷的。

單獨給秒殺建立一個數據庫，為秒殺服務，表的設計也是竟可能的簡單點，現在的互聯網架構部署都是分庫的。

至于表就看大家怎么設計了，該設置索引的地方還是要設置索引的，建完后記得用explain看看SQL的執行計劃。（不了解的小伙伴也沒事，MySQL章節去康康）

分布式事務

這為啥我不放在后端而放到最后來講呢？

因為上面的任何一步都是可能出錯的，而且我們是在不同的服務里面出錯的，那就涉及分布式事務了，但是分布式事務大家想的是一定要成功什么的那就不對了，還是那句話，幾個請求丟了就丟了，要保證時效和服務的可用可靠。

所以TCC和最終一致性其實不是很適合，TCC開發成本很大，所有接口都要寫三次，因為涉及TCC的三個階段。

最終一致性基本上都是靠輪訓的操作去保證一個操作一定成功，那時效性就大打折扣了。

大家覺得不那么可靠的**兩段式（2PC）和三段式（3PC）**就派上用場了，他們不一定能保證數據最終一致，但是效率上還算ok。

總結

到這里我想我已經基本上把該考慮的點還有對應的解決方案也都說了一下，不知道還有沒有沒考慮到的，但是就算沒考慮到我想我這個設計，應該也能撐住一個完整的秒殺流程。

最后大家再看看這個秒殺系統或許會有新的感悟，是不是一個系統真的沒有大家想的那么簡單，而且我還是有漏掉的細節，這是一定的。

秒殺這章我腦細胞死了很多，考慮了很多個點，最后還是出來了，忍不住給自己點贊！

我們玩歸玩，鬧歸鬧，別拿面試開玩笑。

秒殺不一定是每個同學都會問到的，至少肯定沒Redis基礎那樣常問，但是一旦問到，大家一定要回答到點上。

至少你得說出可能出現的情況，需要注意的情況，以及對于的解決思路和方案，因為這才是一個coder的基本素養，這些你不考慮你也很難去進步。

最后就是需要對整個鏈路比較熟悉，注意是一個完整的鏈路，前端怎么設計的呀，網關的作用呀，怎么解決Redis的并發競爭啊，數據的同步方式呀，MQ的作用啊等等，相信你會有不錯的收獲。