阿里的秒殺系統是怎麼設計的？

背景

我之前寫過一個秒殺系統的文章不過有些許瑕疵，所以我準備在之前的基礎上進行二次創作，不過讓我決心二創秒殺系統的原因是我最近面試了很多讀者，動不動就是秒殺系統把我整矇蔽了，我懵的主要是秒殺系統的細節大家都不知道，甚至不知道電商公司一個秒殺系統的組成部分。

我之前在某電商公司就是做電商活動的，所以這樣的場景和很多解決方案我是比較清楚的，那我就從我自身去帶著大家看看一個秒殺的設計細節以及中間各種解決方案的利弊，以下就是我設計的秒殺系統，幾乎涵蓋了市面上所有秒殺的實現細節：

正文

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

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

你一聽，完了呀，這我們的伺服器哪裡頂得住啊！說真的直接打DB肯定掛，但是別急嘛，有 暖男敖丙在，任何系統我們開始設計之前我們都應該去思考 會出現哪些問題？這裡我羅列了幾個非常經典的問題：

問題

高併發：

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

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

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

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

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

超賣：

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

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

惡意請求：

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

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

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

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

“本文章純屬轉載，如有違規及侵權請聯絡作者刪除”