一個故事講解秒殺設計～

這是個人第 65 篇原創文章

做者 | 悟空聊架構

來源 | 悟空聊架構（ID：PassJava666）

轉載請聯繫受權（微信ID：PassJava）

星球簡介

地點：β-410 星系，A-731電商星球。

時間：新紀元 2036 年。

星球簡介：

• 中文名：A-731電商星球

• 外文名：A-731 Mall

• 分類：行星

• 公轉週期：一年

• 常駐用戶：中間件工做者、各類請求。

• 星球總歷史：二十萬年。

星球危機

我是一個秒殺請求，天天的工做就是將秒殺請求的數據運送給後端工做者。

這天我在 Nginx 轉發服務器上碰見了請求「小空」 ，我跟小空說有重要消息不方便如今告訴他，下班再約，而後就都匆匆趕路了。

我和小空晚上十點下班後來到一家酒吧，點了兩杯 mojito，找了一個角落坐下。

小空：你最近看起來心事重重。

我：你有沒有發現最近咱們星球的訂單數急劇增長，天天有一千萬訂單數據產生，也不是一天、兩天的事了。

小空：難怪我天天加班到晚上十點來運送請求數據。

我：我有個舅舅在航天局上班，告訴我說咱們星球承載不了那麼多請求和訂單數據，不久就會出現「行星大爆炸」 。你可不要透露給別人。

小空：那怎麼辦？

我：咱們能夠去 100 光年外的 T-714 星球，可是隻能經過秒殺通道坐時空穿梭機去那顆星球。並且名額有限制，不知道我有沒有機會登上穿梭機。

我：明天通道會開啓兩次，上午十點和下午兩點。你明天和我一塊兒去吧！

小空：好的。

星球大爆炸

「涉及的知識點：」

• 這裏的行星大爆炸指的是什麼？

  • 因訂單數據量很大，數據庫撐不住了。數據庫可能宕機。

  • 因天天有大量請求發送到服務器，服務器也扛不住了。服務器可能宕機。

• 秒殺通道天天開啓兩次表明了什麼？

  • 「流量錯峯」 ，將流量分攤到兩個秒殺場次。

  • 固然 「流量錯峯」 的手段還有輸入驗證、加入購物車等分攤流量的作法。

秒殺通道

地點：A-731 星球機場

時間：09 : 45

通道

「請前往 T-714 星球的請求旅客到 Y1 站臺排隊等待進入特殊通道， 15 分鐘後開始進入穿梭機大廳」。大廳的廣播連續播放了三遍。

我走向了特殊通道，看到通道旁立着一個牌子：秒殺通道，只給秒殺請求使用。

「涉及知識點：」

• 秒殺場景爲何 單獨弄了條通道？

  • 秒殺業務爲了避免影響系統的其餘業務單獨部署了一套秒殺系統。

  • 總結爲 「服務單一職責 + 獨立部署」

實時大屏

一擡頭看到通道上方有一個大屏，在不斷播放 T-714 星球的照片，以及機票的訂單信息。

T-714 星球

有兩個穿制服的工做者正在大屏旁巡邏。一個制服上印着 Nginx，一個制服上印着 CDN。

Nginx+CDN

「涉及知識點：」

• Nginx 制服：

  • 穿 Nginx 制服的工做者在維護 Nginx 的靜態和動態資源。

  • 商品詳情頁是一個靜態頁面，將這些靜態頁面存儲到 Nginx 服務器上，訪問靜態資源時，請求先到 Nginx，而後 Nginx 服務器經過請求的 URL 連接來匹配是不是訪問的靜態資源。

  • 大屏的商品詳情頁並非經過發送請求從後臺服務器拿到的。其實實現了 「動靜分離」 。

• 一張圖解釋 Nginx 動靜分離

  Nginx 流程圖

  • 靜態資源好比 HTML 文件極少變化，就能夠專門放到一臺服務器上，直接訪問，不須要與後臺服務器交互（好比 Tomcat）。

  • 動態資源好比須要從後臺拿到有多少人購買了商品，發送下單請求來存儲數據，這些都稱做動態資源，不能狹隘的理解爲看得見的資源，廣義上能夠包括獲取邏輯處理的結果，執行存儲數據等操做。

• CDN 制服

  • 什麼是 CDN：CDN 大白話解釋就是用戶就近獲取資源，減小網絡傳輸時間，提升訪問速度。

  • Nginx 上放 HTML文件，而 CDN 上則放 HTML 引入的圖片文件、腳本文件。

  • 穿 CDN 制服的工做者在維護 CDN 的資源。

• 一張流程圖解釋 CDN 工做原理

  CDN 流程圖

驗證通道

時間：10:00

「驗證通道已開啓，請攜帶密碼進入！」 又是播放了三遍廣播。

輸入密碼

「涉及的知識點：」

• 爲何須要密碼？

  • 爲了防止大量模擬的秒殺請求進入業務處理流程，因此先加一道驗證，丟棄這些假請求。

  • 怎麼作到的？前端網頁先發送請求拿到密碼，點擊搶購時，請求體中攜帶加密密碼，後端校驗密碼是否匹配。能夠經過 MD5 加密。

• 總結爲 「秒殺請求加密」 。

穿梭機大廳

穿梭機大廳

通過驗證通道的篩選後，有一半的假請求被擋在門外，像我這種拿到了正確密碼的順利進入了穿梭機大廳。

來到大廳，發現大廳的正中央擺放着一個顯示器，上面顯示的紅色數字 100 赫然映入眼中。

顯示屏的左手邊站着一位穿着 Redis 統一制服的靚女。在一旁的我偷聽到原來她是控制顯示器顯示穿梭機剩餘數量的。若是數字變爲 0 ，則表示穿梭機已經所有被佔用，後來的人就得無功而返了。

Redis

「涉及的知識點：」

• 秒殺場景中，查詢剩餘庫存並非直接查數據庫，而是查 Redis 緩存的。

• 爲何是查緩存？由於查緩存的速度要遠遠快於查數據庫，減小了響應時間，並且對數據庫的壓力減少了不少。若是不少查庫存的請求都到數據庫了，那數據庫就要崩了，並且數據庫幹不了其餘的活了。

搶票

顯示屏的右手邊站着一位西裝筆挺的年輕帥哥，看到他的袖口上掛着一個紅袖章，印着 Redisson 字樣。他一臉嚴肅的模樣，對大廳內黑壓壓一片的請求熟視無睹。多是見慣了這種場景吧。

正在打量這位帥哥時，發現他的左手拿着一疊機票，沒錯，有了一張機票就能夠登入穿梭機了。我以百米衝速的速度到達了他面前，到達他面前時，已經有十幾個請求也到了他身邊，他按照先來後到的順序依次發放機票，到個人時候，機票已經只剩幾張了，慶幸的是個人百米衝速幫我搶到了一張機票。我問帥哥是否能夠再發一張票給我，他拒絕了。

每一次發放票，穿 Redis 制服的靚女都會操做顯示屏，讓其數量減一。

十秒鐘後，票已經發完，顯示屏顯示數字 0 。

「涉及的知識點：」

• Redisson 是啥呢？Redis 客戶端，解決了分佈式的一些常見問題。

• 這裏其實用到了 Redisson 的信號量功能，總共有 100 張票，也就是 100 個信號量，並且票的數量不會由於多線程併發或分佈式系統的緣由而致使票的數量被超賣。好比賣出了 101 張票。

• 每一個人只能得到一張票，這就是秒殺系統中涉及到的冪等性校驗，不能重複搶票。

售票窗口

登機牌

登機牌

發放機票的帥哥告訴我，拿到票後，到 A 窗口排隊付款，才能拿到登記牌。因而我和另外 99 個請求一塊兒在 A 窗口排隊了。

看到一個請求想要放棄付款了，說是機票太貴了，而後準備離開大廳時，被髮放機票的帥哥攔住了，他問請求是否要考慮下，有 15 分鐘的考慮時間，若是請求仍是以爲不行，能夠將機票還給他，他能夠再發放給其餘人。

隊列削峯

「涉及的知識點：」

• 秒殺系統中經常使用的「隊列削峯」 。秒殺成功的請求，進入隊列，慢慢建立訂單、扣減庫存。

• 秒殺成功後，快速告訴用戶已經秒殺成功，而不是等待訂單完再告訴用戶，那用戶就要多等一會了，影響體驗。

• 爲何要作隊列削峯？成功的請求沒必要一會兒都去數據庫建立訂單，這樣對數據庫的壓力也會小一些。

• 在秒殺場景中，頗有可能有用戶搶到了可是不付款的場景，這個時候庫存是要加回去的，能夠提供給其餘用戶。

啓航

訂單建立成功後，我順利拿到了登機牌，經過了登機牌的校驗後，成功登上了穿梭機。

出發，去往 T-714 星球。據說那個星球的數據庫進行了分庫分表、服務也拆分紅了微服務。

啓航

總結

上面經過科幻小說的方式來說解了秒殺系統中關注的點，下面是對秒殺系統關注的八大點的一個總結：

秒殺場景關注點

• 服務單一職責、獨立部署

• 庫存預熱、快速扣減

• 秒殺連接加密

• 動靜分離

• 惡意請求攔截

• 流量錯峯

• 限流&熔斷&降級

• 隊列削峯

只講原理好像不得勁，是否是要來篇實站？

- END -

 

你好，我是悟空哥，「7年項目開發經驗，全棧工程師，開發組長，超喜歡圖解編程底層原理」。我還手寫了2個小程序，Java刷題小程序，PMP刷題小程序，點擊個人公衆號菜單打開！另外有111本架構師資料以及1000道Java面試題，都整理成了PDF，能夠關注公衆號 「悟空聊架構」 回覆 悟空 領取優質資料。

「轉發->在看->點贊->收藏->評論！！！」  是對我最大的支持！

 

我是悟空，努力變身超級賽亞人！咱們下期見！

點亮，服務器三年不宕機

 

 

本文分享自微信公衆號 - 悟空聊架構（PassJava666）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。