秒殺系統設計

背景

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

我以前在某電商公司就是作電商活動的，因此這樣的場景和不少解決方案我是比較清楚的，那我就從我自身去帶着你們看看一個秒殺的設計細節以及中間各類解決方案的利弊，如下就是我設計的秒殺系統，幾乎涵蓋了市面上全部秒殺的實現細節：

正文

首先設計一個系統以前，咱們須要先確認咱們的業務場景是怎麼樣子的，我就帶着你們一塊兒假設一個場景好吧。

咱們現場要賣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好難啊！

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

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

咱們從前端開始：

前端

秒殺系統廣泛都是商城網頁、H五、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的做用啊等等，相信你會有不錯的收穫。

不知道這是一次成功仍是失敗的二創，我裏面全部提到的技術細節我都寫了對應的文章，你們能夠關注我去歷史文章看看，天色已晚，我溜了。