一、理解秒殺系統
要做一個秒殺系統，首先要理解秒殺系統。秒殺系統主要解決兩個問題，一個是併發讀，一個是併發寫。併發讀的核心優化概念是儘量減少用戶到服務端來讀數據，或者讓用戶讀更少的數據。併發寫的處理原則也一樣，它要求我們在數據庫層面獨立出來一個庫，做特殊的處理。
二、秒殺系統設計原則
秒殺系統本質上就是一個滿足大併發、高性能和高可用的分佈式系統。對於秒殺系統，請求數據要儘量少，路徑要儘量短，依賴要儘量少，以及不要有單點。
- 數據要儘量少。指用戶請求的數據能少就少。請求的數據包括上傳給系統的數據和系統返回給用戶的數據（通常就是網頁）。不管是請求數據還是返回數據都需要處理器做處理，而服務器在寫網絡時都需要亞索和字符編碼，這些都非常消耗CPU。所以減少傳輸的數據量可以顯著減少CPU的使用。例如：我們可以簡化秒殺頁面的大小，去掉不必要的頁面裝修效果。
- 請求數要儘量少。一次可以請求多個文件，減少請求次數。
- 路徑要儘量短。所謂路徑就是用戶發出請求到返回數據這個過程中需求經過的中間節點數。縮短請求路徑可以增加可靠性。要縮短訪問路徑，就是多個相互強依賴的應用合併部署到一起，把遠程方法調用變成JVM內部的方法調用。
- 不要有單點。因爲單點意味着沒有備份，風險不可控。分佈式系統最重要的原則就是消除“單點”。
三、如何減少數據量
用戶請求的數據可以分爲“靜態數據”和“動態數據”。主要區別就是看輸出的數據是否包含URL、瀏覽者、時間等私密數據。個性化的私密數據是動態數據，公有的頁面是靜態數據。
可以把靜態數據進行緩存，比如商品圖片等。這樣請求的數據量就會減少，減少系統壓力。在將整個系統做動靜分離後，可以將Cache進一步前移到CDN上，因爲CDN離用戶更近，效果會更好。
四、流量削峯
對於秒殺系統，當秒殺活動開啓時，會有巨量的流量瞬間涌進來。服務器的處理能力是恆定的，一下子處理不了這麼多請求。爲解決此問題，需要流量削峯。
- 排隊
要對流量進行削峯，最容易想到的解決方案就是用消息隊列來緩衝瞬時流量，把同步的直接調用轉換成異步的間接推送。中間通過一個隊列在一端承接瞬時的流量洪峯，在另一端平滑地將消息推送出去。在這裏，消息隊列就像水庫一樣，攔蓄上游的洪水，削減進入下游河道的洪峯流量，從而達到減免洪水災害的目的。
如果流量洪峯持續一段時間達到消息隊列的處理上限，消息隊列同樣會被壓垮。
- 答題
增加答題環節可以延緩請求，起到對流量進行削峯的作用，從而讓系統能夠更好的支持瞬時的流量高峯。這個功能就是把峯值的下單請求拉長，從以前的1s之內延長到2s-10s。利用延長的時間，可以大大減緩服務器的壓力。
- 分層過濾
加入請求分別經過CDN、前臺讀系統、後臺系統和數據庫這幾層。那麼，大部分數據和流量在用戶瀏覽器或者CDN上讀取，這一層可以攔截大部分數據的請求。經過前臺系統時數據儘量走Cache，過濾一些無效的請求。第三步數據到後臺系統，主要做數據的二次校驗，這樣數據進一步減少。這樣就像漏斗一樣，儘量把數據量和請求量一層一層地過濾和減少了。
分層過濾的核心思想是，在不同層次儘可能地過濾掉無效請求，讓“漏斗”最末端的纔是有效請求。
五、減庫存
在正常的電商平臺中，用戶的實際購買過程分爲兩個步驟：下單和付款。下單之後，只有完成付款纔算真正購買。減庫存操作一般有如下幾種方式：
- 下單減庫存。即當買家下單後，在商品的總庫存中減去買家購買數量。下單建庫存是最簡單的減庫存方式，也是控制最精確的一種，這樣一定不會出現超賣的情況。但是，有些人下單後並不會付款。
- 付款減庫存。即買家下單後，並不立即減庫存，而是等到用戶付款之後才真正減庫存，可能會出現超賣問題。因爲併發較高，有可能出現買家下單後付不了款的情況，因爲商品已經被其他人買走了。
- 預扣庫存。買家下單後，庫存爲其保留一段時間，超過這個時間，庫存會自動釋放，釋放後其他買家就可以繼續購買。
由於參加秒殺的商品，一般都是“搶到就是賺到”，所以下單後卻不付款的情況比較少，再加上賣家對秒殺商品的庫存有嚴格限制，所以秒殺商品採用“下單建庫存”更加合理。