阿里的秒殺系統(tǒng)是如何設(shè)計(jì)的？

背景

我之前寫過一個(gè)秒殺系統(tǒng)的文章不過有些許瑕疵，所以我準(zhǔn)備在之前的基礎(chǔ)上進(jìn)行二次創(chuàng)作，不過讓我決心二創(chuàng)秒殺系統(tǒng)的原因是我最近面試了很多讀者，動(dòng)不動(dòng)就是秒殺系統(tǒng)把我整蒙蔽了，我懵的主要是秒殺系統(tǒng)的細(xì)節(jié)大家都不知道，甚至不知道電商公司一個(gè)秒殺系統(tǒng)的組成部分。

我之前在某電商公司就是做電商活動(dòng)的，所以這樣的場(chǎng)景和很多解決方案我是比較清楚的，那我就從我自身去帶著大家看看一個(gè)秒殺的設(shè)計(jì)細(xì)節(jié)以及中間各種解決方案的利弊，以下就是我設(shè)計(jì)的秒殺系統(tǒng)，幾乎涵蓋了市面上所有秒殺的實(shí)現(xiàn)細(xì)節(jié)：

正文

首先設(shè)計(jì)一個(gè)系統(tǒng)之前，我們需要先確認(rèn)我們的業(yè)務(wù)場(chǎng)景是怎么樣子的，我就帶著大家一起假設(shè)一個(gè)場(chǎng)景好吧。

我們現(xiàn)場(chǎng)要賣1000件下面這個(gè)嬰兒紙尿褲，然后我們根據(jù)以往這樣秒殺活動(dòng)的數(shù)據(jù)經(jīng)驗(yàn)來看，目測(cè)來?yè)屵@100件紙尿褲的人足足有10萬人。（南極人打錢?。?/p>

你一聽，完了呀，這我們的服務(wù)器哪里頂?shù)米“?！說真的直接打DB肯定掛，但是別急嘛，有暖男敖丙在，任何系統(tǒng)我們開始設(shè)計(jì)之前我們都應(yīng)該去思考會(huì)出現(xiàn)哪些問題？這里我羅列了幾個(gè)非常經(jīng)典的問題：

問題

高并發(fā)：

是的高并發(fā)這個(gè)是我們想都不用想的一個(gè)點(diǎn)，一瞬間這么多人進(jìn)來這不是高并發(fā)什么時(shí)候是呢？

是吧，秒殺的特點(diǎn)就是這樣時(shí)間極短、 瞬間用戶量大。

正常的店鋪營(yíng)銷都是用極低的價(jià)格配合上短信、APP的精準(zhǔn)推送，吸引特別多的用戶來參與這場(chǎng)秒殺，爽了商家苦了開發(fā)呀。

秒殺大家都知道如果真的營(yíng)銷到位，價(jià)格誘人，幾十萬的流量我覺得完全不是問題，那單機(jī)的Redis我感覺3-4W的QPS還是能頂?shù)米〉模窃俑吡司蜎]辦法了，那這個(gè)數(shù)據(jù)隨便搞個(gè)熱銷商品的秒殺可能都不止了。

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

超賣：

但凡是個(gè)秒殺，都怕超賣，我這里舉例的只是尿不濕，要是換成100個(gè)MacBook Pro，商家的預(yù)算經(jīng)費(fèi)賣100個(gè)可以賺點(diǎn)還可以造勢(shì)，結(jié)果你寫錯(cuò)程序多賣出去200個(gè)，你不發(fā)貨用戶投訴你，平臺(tái)封你店，你發(fā)貨就血虧，你怎么辦？ （沒事看了敖丙的文章直接不怕）

那最后只能殺個(gè)開發(fā)祭天解氣了，秒殺的價(jià)格本來就低了，基本上都是不怎么賺錢的，超賣了就恐怖了呀，所以超賣也是很關(guān)鍵的一個(gè)點(diǎn)。

惡意請(qǐng)求：

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

那簡(jiǎn)單啊，我知道你什么時(shí)候搶，我搞個(gè)幾十臺(tái)機(jī)器搞點(diǎn)腳本，我也模擬出來十幾萬個(gè)人左右的請(qǐng)求，那我是不是意味著我基本上有80%的成功率了。

真實(shí)情況可能遠(yuǎn)遠(yuǎn)不止，因?yàn)闄C(jī)器請(qǐng)求的速度比人的手速往往快太多了，在貴州的敖丙我每年回家搶高鐵票都是秒光的，我也不知道有沒有黃牛的功勞，我要Diss你，黃牛。杰倫演唱會(huì)門票搶不到，我也Diss你。

Tip：科普下，小道消息了解到的，黃牛的搶票系統(tǒng)，比國(guó)內(nèi)很多小公司的系統(tǒng)還吊很多，架構(gòu)設(shè)計(jì)都是頂級(jí)的，我用頂配的服務(wù)加上頂配的架構(gòu)設(shè)計(jì)，你還想看演唱會(huì)？還想回家？

不過不用黃牛我回家都難，我們?cè)瀑F川跟我一樣要回家過年的仔太多了555！

鏈接暴露：

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

相信是個(gè)開發(fā)同學(xué)都對(duì)這個(gè)畫面一點(diǎn)都不陌生吧，懂點(diǎn)行的仔都可以打開谷歌的開發(fā)者模式，然后看看你的網(wǎng)頁(yè)代碼，有的就有URL，但是我寫VUE的時(shí)候是事件觸發(fā)然后去調(diào)用文件里面的接口看源碼看不到，但是我可以點(diǎn)擊一下查看你的請(qǐng)求地址啊，不過你好像可以對(duì)按鈕在秒殺前置灰。

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

數(shù)據(jù)庫(kù)：

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

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

程序員：我TM好難??！

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

我會(huì)從我設(shè)計(jì)的秒殺系統(tǒng)從上到下去給大家介紹我們正常電商秒殺系統(tǒng)在每一層做了些什么，每一層存在的問題，難點(diǎn)等。

我們從前端開始：

前端

秒殺系統(tǒng)普遍都是商城網(wǎng)頁(yè)、H5、APP、小程序這幾項(xiàng)。

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

資源靜態(tài)化：

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

秒殺鏈接加鹽：

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

我知道url了，那我通過程序不斷獲取最新的北京時(shí)間，可以達(dá)到毫秒級(jí)別的，我就在00毫秒的時(shí)候請(qǐng)求，我敢說絕對(duì)比你人工點(diǎn)的成功率大太多了，而且我可以一毫秒發(fā)送N次請(qǐng)求，搞不好你賣100個(gè)產(chǎn)品我全拿了。

那這種情況怎么避免？

簡(jiǎn)單，把URL動(dòng)態(tài)化，就連寫代碼的人都不知道，你就通過MD5之類的摘要算法加密隨機(jī)的字符串去做url，然后通過前端代碼獲取url后臺(tái)校驗(yàn)才能通過。

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

后面我會(huì)說。

限流：

限流這里我覺得應(yīng)該分為前端限流和后端限流。

物理控制：

大家有沒有發(fā)現(xiàn)沒到秒殺前，一般按鈕都是置灰的，只有時(shí)間到了，才能點(diǎn)擊。

這是因?yàn)榕麓蠹以跁r(shí)間快到的最后幾秒秒瘋狂請(qǐng)求服務(wù)器，然后還沒到秒殺的時(shí)候基本上服務(wù)器就掛了。

這個(gè)時(shí)候就需要前端的配合，定時(shí)去請(qǐng)求你的后端服務(wù)器，獲取最新的北京時(shí)間，到時(shí)間點(diǎn)再給按鈕可用狀態(tài)。

按鈕可以點(diǎn)擊之后也得給他置灰?guī)酌?，不然他一樣在開始之后一直點(diǎn)的。

你敢說你們秒殺的時(shí)候不是這樣的？

前端限流：這個(gè)很簡(jiǎn)單，一般秒殺不會(huì)讓你一直點(diǎn)的，一般都是點(diǎn)擊一下或者兩下然后幾秒之后才可以繼續(xù)點(diǎn)擊，這也是保護(hù)服務(wù)器的一種手段。

后端限流：秒殺的時(shí)候肯定是涉及到后續(xù)的訂單生成和支付等操作，但是都只是成功的幸運(yùn)兒才會(huì)走到那一步，那一旦100個(gè)產(chǎn)品賣光了，return了一個(gè)false，前端直接秒殺結(jié)束，然后你后端也關(guān)閉后續(xù)無效請(qǐng)求的介入了。

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

我們賣1000件商品，請(qǐng)求有10W，我們不需要把十萬都放進(jìn)來，你可以放1W請(qǐng)求進(jìn)來，然后再進(jìn)行操作，因?yàn)槊霘?duì)于用戶本身就是黑盒的，所以你怎么做的他們是沒感知的，至于為啥放1W進(jìn)來，而不是剛好1000，是因?yàn)闀?huì)丟掉一些薅羊毛的用戶，至于怎么判斷，后面的風(fēng)控階段我會(huì)說。

Nginx：

Nginx大家想必都不陌生了吧，這玩意是高性能的web服務(wù)器，并發(fā)也隨便頂幾萬不是夢(mèng)，但是我們的Tomcat只能頂幾百的并發(fā)呀，那簡(jiǎn)單呀負(fù)載均衡嘛，一臺(tái)服務(wù)幾百，那就多搞點(diǎn)，在秒殺的時(shí)候多租點(diǎn)流量機(jī)。

Tip：據(jù)我所知國(guó)內(nèi)某大廠就是在去年春節(jié)活動(dòng)期間租光了亞洲所有的服務(wù)器，小公司也很喜歡在雙十一期間買流量機(jī)來頂住壓力。

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

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

風(fēng)控

我可以明確的告訴大家，前面的所有措施還是攔不住很多羊毛黨，因?yàn)樗麄兪菍I(yè)的團(tuán)隊(duì)，他們可以注冊(cè)很多賬號(hào)來薅你的羊毛，而且不用機(jī)器請(qǐng)求，就用群控，操作幾乎跟真實(shí)用戶一模一樣。

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

這個(gè)時(shí)候就需要風(fēng)控同學(xué)的介入了，在請(qǐng)求到達(dá)后端之前，風(fēng)控可以根據(jù)賬號(hào)行為分析出這個(gè)賬號(hào)機(jī)器人的概率大不大，我現(xiàn)在負(fù)責(zé)公司的某些特殊系統(tǒng)，每個(gè)用戶的行為都是會(huì)送到我們大數(shù)據(jù)團(tuán)隊(duì)進(jìn)行分析處理，給你打上對(duì)應(yīng)標(biāo)簽的。

那黑客其實(shí)也有辦法：養(yǎng)號(hào)

他們?nèi)ズ谑匈I真實(shí)用戶有過很多記錄的賬號(hào)，買到了還不閑著，幫他們?nèi)ベ?gòu)物啥的，讓系統(tǒng)無法識(shí)別他們是黑號(hào)還是真實(shí)用戶的號(hào)。

怎么辦？

通殺！是的沒有辦法，只能通殺了，通殺的意思就是，我們通過風(fēng)管分析出來這個(gè)用戶是真實(shí)用戶的概率沒有其他用戶概率大，那就認(rèn)為他是機(jī)器了，丟棄他的請(qǐng)求。

之前的限流我們放進(jìn)來10000個(gè)請(qǐng)求，但是我們真正的庫(kù)存只有1000個(gè)，那我們就算出最有可能是真實(shí)用戶的1000人進(jìn)行秒殺，丟棄其他請(qǐng)求，因?yàn)槊霘⒈緛砭褪呛诤胁僮鞯?，用戶層面是無感知的，這樣設(shè)計(jì)能讓真實(shí)的用戶買到東西，還可以減少自己被薅羊毛的概率。

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

后端

服務(wù)單一職責(zé)：

設(shè)計(jì)個(gè)能抗住高并發(fā)的系統(tǒng)，我覺得還是得單一職責(zé)。

什么意思呢，大家都知道現(xiàn)在設(shè)計(jì)都是微服務(wù)的設(shè)計(jì)思想，然后再用分布式的部署方式。

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

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

Redis集群：

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

庫(kù)存預(yù)熱：

秒殺的本質(zhì)，就是對(duì)庫(kù)存的搶奪，每個(gè)秒殺的用戶來你都去數(shù)據(jù)庫(kù)查詢庫(kù)存校驗(yàn)庫(kù)存，然后扣減庫(kù)存，撇開性能因數(shù)，你不覺得這樣好繁瑣，對(duì)業(yè)務(wù)開發(fā)人員都不友好，而且數(shù)據(jù)庫(kù)頂不住啊。

開發(fā)：你tm總算為我著想一次了。

那怎么辦？

我們都知道數(shù)據(jù)庫(kù)頂不住但是他的兄弟非關(guān)系型的數(shù)據(jù)庫(kù)Redis能頂??！

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

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

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

事務(wù)：

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

限流&降級(jí)&熔斷&隔離：

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

消息隊(duì)列（削峰填谷）：

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

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

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

你可以把它放消息隊(duì)列，然后一點(diǎn)點(diǎn)消費(fèi)去改庫(kù)存就好了嘛，不過單個(gè)商品其實(shí)一次修改就夠了，我這里說的是某個(gè)點(diǎn)多個(gè)商品一起秒殺的場(chǎng)景，像極了雙十一零點(diǎn)。

數(shù)據(jù)庫(kù)

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

單獨(dú)給秒殺建立一個(gè)數(shù)據(jù)庫(kù)，為秒殺服務(wù)，表的設(shè)計(jì)也是竟可能的簡(jiǎn)單點(diǎn)，現(xiàn)在的互聯(lián)網(wǎng)架構(gòu)部署都是分庫(kù)的。

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

分布式事務(wù)

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

因?yàn)樯厦娴娜魏我徊蕉际强赡艹鲥e(cuò)的，而且我們是在不同的服務(wù)里面出錯(cuò)的，那就涉及分布式事務(wù)了，但是分布式事務(wù)大家想的是一定要成功什么的那就不對(duì)了，還是那句話，幾個(gè)請(qǐng)求丟了就丟了，要保證時(shí)效和服務(wù)的可用可靠。

所以TCC和最終一致性其實(shí)不是很適合，TCC開發(fā)成本很大，所有接口都要寫三次，因?yàn)樯婕癟CC的三個(gè)階段。

最終一致性基本上都是靠輪訓(xùn)的操作去保證一個(gè)操作一定成功，那時(shí)效性就大打折扣了。

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

總結(jié)

到這里我想我已經(jīng)基本上把該考慮的點(diǎn)還有對(duì)應(yīng)的解決方案也都說了一下，不知道還有沒有沒考慮到的，但是就算沒考慮到我想我這個(gè)設(shè)計(jì)，應(yīng)該也能撐住一個(gè)完整的秒殺流程。

最后大家再看看這個(gè)秒殺系統(tǒng)或許會(huì)有新的感悟，是不是一個(gè)系統(tǒng)真的沒有大家想的那么簡(jiǎn)單，而且我還是有漏掉的細(xì)節(jié)，這是一定的。

秒殺這章我腦細(xì)胞死了很多，考慮了很多個(gè)點(diǎn)，最后還是出來了，忍不住給自己點(diǎn)贊！

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

秒殺不一定是每個(gè)同學(xué)都會(huì)問到的，至少肯定沒Redis基礎(chǔ)那樣常問，但是一旦問到，大家一定要回答到點(diǎn)上。

至少你得說出可能出現(xiàn)的情況，需要注意的情況，以及對(duì)于的解決思路和方案，因?yàn)檫@才是一個(gè)coder的基本素養(yǎng)，這些你不考慮你也很難去進(jìn)步。

最后就是需要對(duì)整個(gè)鏈路比較熟悉，注意是一個(gè)完整的鏈路，前端怎么設(shè)計(jì)的呀，網(wǎng)關(guān)的作用呀，怎么解決Redis的并發(fā)競(jìng)爭(zhēng)啊，數(shù)據(jù)的同步方式呀，MQ的作用啊等等，相信你會(huì)有不錯(cuò)的收獲。