吊打面試官——秒殺系統設計

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

場景

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

 

你一聽，完了呀，這咱們的服務器哪裏頂得住啊！說真的直接打DB確定掛。可是別急嘛，有暖男敖丙在，咱們在開始以前應該先思考下會出現哪些問題？

問題

高併發：

是的高併發這個是咱們想都不用想的一個點，一瞬間這麼多人進來這不是高併發何時是呢？

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

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

秒殺你們都知道若是真的營銷到位，價格誘人，幾十萬的流量我以爲徹底不是問題，那單機的Redis我感受3-4W的QPS仍是能頂得住的，可是再高了就沒辦法了，那這個數據隨便搞個熱銷商品的秒殺可能都不止了。

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

 

超賣：

但凡是個秒殺，都怕超賣，我這裏舉例的只是尿不溼，要是換成100個華爲MatePro30，商家的預算經費賣100個能夠賺點還能夠造勢，結果你寫錯程序多賣出去200個，你不發貨用戶投訴你，平臺封你店，你發貨就血虧，你怎麼辦？

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

 

惡意請求：

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

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

真實狀況可能遠遠不止，由於機器請求的速度比人的手速每每快太多了。

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

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

連接暴露：

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

 

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

無論怎麼樣子都有危險，撇開外面的全部的東西你都擋住了，你賣這個東西實在便宜得過度，有誘惑力，你能保證開發不動心？開發知道地址，在秒殺的時候本身提早請求。。。（開發：怎麼TM又是我）

 

數據庫：

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

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

程序員：我TM好難啊！

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

服務單一職責：

設計個能抗住高併發的系統，我以爲仍是得單一職責。

什麼意思呢，你們都知道如今設計都是微服務的設計思想，而後再用分佈式的部署方式

也就是咱們下單是有個訂單服務，用戶登陸管理等有個用戶服務等等，那爲啥咱們不給秒殺也開個服務，咱們把秒殺的代碼業務邏輯放一塊兒。

單獨給他創建一個數據庫，如今的互聯網架構部署都是分庫的，同樣的就是訂單服務對應訂單庫，秒殺咱們也給他創建本身的秒殺庫。

至於表就看你們怎麼設計了，該設置索引的地方仍是要設置索引的，建完後記得用explain看看SQL的執行計劃。（不瞭解的小夥伴也沒事，MySQL章節我會說的）

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

秒殺連接加鹽：

咱們上面說了連接要是提早暴露出去可能有人直接訪問url就提早秒殺了，那又有小夥伴要說了我作個時間的校驗就行了呀，那我告訴你，知道連接的地址比起頁面人工點擊的仍是有很大優點。

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

 

那這種狀況怎麼避免？

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

暖男我呢，又準備了一個簡單的url加密給你們嚐嚐鮮，還不點個贊？

 

Redis集羣：

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

 

Nginx：

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

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

 

這樣一對比是否是以爲你的集羣能頂不少了。

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

資源靜態化：

秒殺通常都是特定的商品還有頁面模板，如今通常都是先後端分離的，因此頁面通常都是不會通過後端的，可是前端也要本身的服務器啊，那就把能提早放入cdn服務器的東西都放進去，反正把全部能提高效率的步驟都作一下，減小真正秒殺時候服務器的壓力。

按鈕控制：

你們有沒有發現沒到秒殺前，通常按鈕都是置灰的，只有時間到了，才能點擊。

這是由於怕你們在時間快到的最後幾秒秒瘋狂請求服務器，而後還沒到秒殺的時候基本上服務器就掛了。

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

按鈕能夠點擊以後也得給他置灰幾秒，否則他同樣在開始以後一直點的。你敢說大家秒殺的時候不是這樣的？

 

限流：

限流這裏我以爲應該分爲前端限流和後端限流。

前端限流：這個很簡單，通常秒殺不會讓你一直點的，通常都是點擊一下或者兩下而後幾秒以後才能夠繼續點擊，這也是保護服務器的一種手段。

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

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

庫存預熱：

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

開發：你tm總算爲我着想一次了。

 

那怎麼辦？

咱們都知道數據庫頂不住可是他的兄弟非關係型的數據庫Redis能頂啊！

那不簡單了，咱們要開始秒殺前你經過定時任務或者運維同窗提早把商品的庫存加載到Redis中去，讓整個流程都在Redis裏面去作，而後等秒殺結束了，再異步的去修改庫存就行了。

可是用了Redis就有一個問題了，咱們上面說了咱們採用主從，就是咱們會去讀取庫存而後再判斷而後有庫存纔去減庫存，正常狀況沒問題，可是高併發的狀況問題就很大了。

多品幾遍！！！就好比如今庫存只剩下1個了，咱們高併發嘛，4個服務器一塊兒查詢了發現都是還有1個，那你們都以爲是本身搶到了，就都去扣庫存，那結果就變成了-3，是的只有一個是真的搶到了，別的都是超賣的。咋辦？

Lua：

Lua 腳本功能是 Reids在 2.6 版本的最大亮點， 經過內嵌對 Lua 環境的支持， Redis 解決了長久以來不能高效地處理 CAS （check-and-set）命令的缺點， 而且能夠經過組合使用多個命令， 輕鬆實現之前很難實現或者不能高效實現的模式。

Lua腳本是相似Redis事務，有必定的原子性，不會被其餘命令插隊，能夠完成一些Redis事務性的操做。這點是關鍵。

知道原理了，咱們就寫一個腳本把判斷庫存扣減庫存的操做都寫在一個腳本丟給Redis去作，那到0了後面的都Return False了是吧，一個失敗了你修改一個開關，直接擋住全部的請求，而後再作後面的事情嘛。

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

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

 

削峯填谷：

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

Tip：可能小夥伴說咱們業務達不到這個量級，不必。可是我想說咱們寫代碼，就不該該寫出有邏輯漏洞的代碼，至少之後公司體量上去了，別人一看竟然不用改代碼，一看代碼做者是敖丙？有點東西！

你能夠把它放消息隊列，而後一點點消費去改庫存就行了嘛，不過單個商品其實一次修改就夠了，我這裏說的是某個點多個商品一塊兒秒殺的場景，像極了雙十一零點。

總結

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