我是一個秒殺請求，正在逃離這顆星球…

• 2020 年 10 月 22 日
• 筆記
• 分散式, 秒殺, 講故事

星球簡介

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

時間：新紀元 2036 年。

星球簡介：

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

• 外文名：A-731 Mall

• 分類：行星

• 公轉周期：一年

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

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

星球危機

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

這天我在 Nginx 轉發伺服器上遇見了請求小空 ，我跟小空說有重要消息不方便在現在告訴他，下班再約，然後就都匆匆趕路了，因為我倆都要快速將請求數據運送到訂單星球去。

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

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

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

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

我：我有個舅舅在航天局上班，告訴我說我們星球承載不了那麼多請求和訂單數據，不久就會出現行星大爆炸 。

小空：那怎麼辦？

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

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

小空：好的。

涉及的知識點：

• 這裡的行星大爆炸指的是什麼？
  • 因訂單數據量很大，資料庫撐不住了。資料庫可能宕機。
  • 因每天有大量請求發送到伺服器，伺服器也扛不住了。伺服器可能宕機。
• 秒殺通道每天開啟兩次代表了什麼？
  • 流量錯峰 ，將流量分攤到兩個秒殺場次。
  • 當然流量錯峰 的手段還有輸入驗證、加入購物車等分攤流量的操作。

秒殺通道

地點：A-731 星球機場

時間：09 : 45

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

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

涉及知識點：

• 秒殺場景為什麼單獨弄了條通道？
  • 秒殺業務為了不影響系統的其他業務單獨部署了一套秒殺系統。
  • 總結為服務單一職責 + 獨立部署

實時大屏

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

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

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6P1fVR1b-1603325598167)(//cdn.jayh.club/blog/20201021/162136369.png)]

涉及知識點：

• Nginx 制服：

  • 穿 Nginx 制服的工作者在維護 Nginx 的靜態和動態資源。
  • 商品詳情頁是一個靜態頁面，將這些靜態頁面存儲到 Nginx 伺服器上，訪問靜態資源時，請求先到 Nginx，然後 Nginx 伺服器通過請求的 URL 鏈接來匹配是否是訪問的靜態資源。
  • 大屏的商品詳情頁並不是通過發送請求從後台伺服器拿到的。其實實現了動靜分離 。

• 一張圖解釋 Nginx 動靜分離

  

  • 靜態資源比如 HTML 文件極少變化，就可以專門放到一台伺服器上，直接訪問，不需要與後台伺服器交互（比如 Tomcat）。
  • 動態資源比如需要從後台拿到有多少人購買了商品，發送下單請求來存儲數據，這些都稱作動態資源，不能狹隘的理解為看得見的資源，廣義上可以包括獲取邏輯處理的結果，執行存儲數據等操作。

• CDN 制服

  • 什麼是 CDN：CDN 大白話解釋就是用戶就近獲取資源，減少網路傳輸時間，提高訪問速度。
  • Nginx 上放 HTML文件，而 CDN 上則放 HTML 引入的圖片文件、腳本文件。
  • 穿 CDN 制服的工作者在維護 CDN 的資源。

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

  

驗證通道

時間：10:00

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

涉及的知識點：

• 為什麼需要密碼？
  • 為了防止大量模擬的秒殺請求進入業務處理流程，所以先加一道驗證，丟棄這些假請求。
  • 怎麼做到的？前端網頁先發送請求拿到密碼，點擊搶購時，請求體中攜帶加密密碼，後端校驗密碼是否匹配。可以通過 MD5 加密。
• 總結為秒殺請求加密 。

穿梭機大廳

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

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

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

涉及的知識點：

• 秒殺場景中，查詢剩餘庫存並不是直接查資料庫，而是查 Redis 快取的。
• 為什麼是查快取？因為查快取的速度要遠遠快於查資料庫，減少了響應時間，而且對資料庫的壓力減小了很多。如果很多查庫存的請求都到資料庫了，那資料庫就要崩了，而且資料庫幹不了其他的活了。

搶票

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

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

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

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

涉及的知識點：

• Redisson 是啥呢？Redis 客戶端，解決了分散式的一些常見問題。
• 這裡其實用到了 Redisson 的訊號量功能，總共有 100 張票，也就是 100 個訊號量，而且票的數量不會因為多執行緒並發或分散式系統的原因而導致票的數量被超賣。比如賣出了 101 張票。
• 每個人只能獲得一張票，這就是秒殺系統中涉及到的冪等性校驗，不能重複搶票。

登機牌

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

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

涉及的知識點：

• 秒殺系統中常用的隊列削峰 。秒殺成功的請求，進入隊列，慢慢創建訂單、扣減庫存。

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

• 為什麼要做隊列削峰？成功的請求不必一下子都去資料庫創建訂單，這樣對資料庫的壓力也會小一些。

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

啟航

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

出發，去往 T-714 星球。聽說那個星球的資料庫進行了分庫分表、服務也拆分成了微服務。

總結

上面通過科幻小說的方式來講解了秒殺系統中關注的點，但並沒有講全，所以下面列出了秒殺系統關注的八大點：

• 服務單一職責、獨立部署
• 庫存預熱、快速扣減
• 秒殺鏈接加密
• 動靜分離
• 惡意請求攔截
• 流量錯峰
• 限流&熔斷&降級
• 隊列削峰

只講原理好像不得勁，是不是要來篇實戰！

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

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

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