你知道的越多，你不知道的越多

點贊再看，養成習慣

GitHub上已經開源 https://github.com/JavaFamily 有一線大廠面試點腦圖和個人聯絡方式，歡迎Star和指教

前言

Redis在網際網路技術儲存方面使用如此廣泛，幾乎所有的後端技術面試官都要在Redis的使用和原理方面對小夥伴們進行360°的刁難。

作為一個在網際網路公司面一次拿一次Offer的麵霸，打敗了無數競爭對手，每次都只能看到無數落寞的身影失望的離開，略感愧疚（請允許我使用一下誇張的修辭手法）。

於是在一個寂寞難耐的夜晚，我痛定思痛，決定開始寫《吊打面試官》系列，希望能幫助各位讀者以後面試勢如破竹，對面試官進行360°的反擊，吊打問你的面試官，讓一同面試的同僚瞠目結舌，瘋狂收割大廠Offer！

絮叨

之前寫了很多Redis相關的知識點，我又大概回頭看了下，除了比較底層的東西沒寫很深之外，我基本上的點都提到過了，我相信如果只是為了應付面試應該是夠了的，但是如果你想把它們真正的吸收納為己用，還是需要大量的知識積累，和很多實際操作的。

就我自己而言Redis在開發過程中實在用得太普遍了，熱點資料的儲存啊，整體效能的提升啊都會用到，但是就像我說的技術就是一把雙刃劍，使用它們隨之而來的問題也會很多的，我在老東家雙十二就遇到快取雪崩問題讓整體服務宕機3分鐘，相必大家都知道阿里今年的雙十一資料了，那三分鐘在這種時候到底值多少錢？真的不敢想象。

Redis的普遍我就拿掘金我自己的認知舉例，不知道對不對，但是目測是對的。

大家看到問題所在了麼？是的熱門的讚的資料不是最新的，我盲猜一波上面的熱門文章是快取。失效時間應該是幾十分鐘的，為啥這麼做呢？

熱門文章是大家共同都會看到的，也就是熱點資料，在那做快取，他是不需要那麼高的實時性的，那下面的文章列表是最新發布的文章，有高實時性的特點，大家訪問多的放在快取還可以給DB減少壓力，我也不知道掘金是不是這麼做的哈，反正道理是這麼個道理了。

那什麼場景是使用Redis比較複雜的場景，而且需要大量中介軟體和業務邏輯去配合的呢？

秒殺！是的就是今天的主題秒殺，我就用我自己的思路帶大家一起看一下，設計一個秒殺從前到後，從內到外到底要技術人員做多少準備。

撈一下

上一期吊打系列我們提到了Redis相關的一些知識，還沒看的小夥伴可以回顧一下 ，這對於這期的閱讀很有幫助，涉及到主從同步、讀寫分離、持久化這樣的知識點。

• 《吊打面試官》系列-Redis基礎
• 《吊打面試官》系列-快取雪崩、擊穿、穿透
• 《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU
• 《吊打面試官》系列-Redis終章凜冬將至、FPX新王登基
• 《吊打面試官》系列-Redis常見面試題（帶答案）

打好基礎才可以寫出更好的程式碼喲！不然就等著產品測試懟你吧。

正文

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

場景

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

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

問題

高併發：

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

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

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

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

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

超賣：

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

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

惡意請求：

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

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

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

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：可能小夥伴說我們業務達不到這個量級，沒必要。但是我想說我們寫程式碼，就不應該寫出有邏輯漏洞的程式碼，至少以後公司體量上去了，別人一看居然不用改程式碼，一看程式碼作者是敖丙？有點東西！

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

總結

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

（有大佬的話給敖丙點多的思路，去GitHub https://github.com/JavaFamily 上給我提，也有我的聯絡）

最後我就畫個完整的流程圖給大家收個尾吧！

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

（這章是真的不要白嫖，每次都看了不點贊，你們想白嫖我麼？你們好壞喲，不過我好喜歡）

總結

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

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

至少你得說出可能出現的情況，需要注意的情況，以及對於的解決思路和方案。

最後就是需要對整個鏈路比較熟悉，注意是一個完整的鏈路，前端怎麼設計的呀，閘道器的作用呀，怎麼解決Redis的併發競爭啊，資料的同步方式呀，MQ的作用啊。

（提到MQ又是一整條的知識鏈路，什麼非同步、削峰、解耦等等，所以面試，我們還是不打沒有把握的勝仗）

流著淚說再見

Redis系列到此是真的要跟大家說再見了，寫了7篇文章，其實很多大佬的思路和片段真心贊，其實大家看出來了我的文章個人風格色彩特別濃厚，我個人在生活中就是這麼說話的，也希望用這種風格把原本枯燥乏味的知識點讓大家都像看小說一樣津津有味的看下去，不知道大傢什麼感受，好的不好的都請給我留言。

我這個系列的我會寫到我GitHub https://github.com/JavaFamily 圖中所有的知識點，以後就麻煩大家多多關照了，我寫作的時間都是業餘時間，基本上週末和晚上的時間都貢獻出來了，我也是個新人很多點也沒接觸到，也要看書看資料才能寫出來，所以有時候還是希望大家多多包涵。

那我們下期見！

下期寫____？

不告訴你，哈哈！

日常求贊

好了各位，以上就是這篇文章的全部內容了，能看到這裡的人呀，都是人才。

我後面會每週都更新幾篇《吊打面試官》系列和網際網路常用技術棧相關的文章，非常感謝人才們能看到這裡，如果這個文章寫得還不錯，覺得「敖丙」我有點東西的話 求點贊