1、啥是秒殺
秒殺場景一般會在電商網站舉行一些活動時遇到。
對於電商網站中一些稀缺或者特價商品，電商網站一般會在約定時間點對其進行限量銷售，因爲這些商品的特殊性，會吸引大量用戶前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。
2、秒殺系統場景特點
- 秒殺一般是訪問請求數量遠遠大於庫存數量，只有少部分用戶能夠秒殺成功
- 秒殺時大量用戶會在同一時間同時進行搶購，網站瞬時訪問流量激增
- 秒殺業務流程比較簡單，一般就是下訂單減庫存
3、秒殺架構設計理念
限流： 鑑於只有少部分用戶能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進入服務後端秒殺程序。
削峯：對於秒殺系統瞬時會有大量用戶涌入，所以在搶購一開始會有很高的瞬間峯值。高峯值流量是壓垮系統很重要的原因，所以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實現削峯的常用的方法有前端添加一定難度的驗證碼後端利用緩存和消息中間件等技術。
異步處理：秒殺系統是一個高併發系統，採用異步處理模式可以極大地提高系統併發量，其實異步處理就是削峯的一種實現方式。
內存緩存：秒殺系統最大的瓶頸一般都是數據庫讀寫，由於數據庫讀寫屬於磁盤IO，性能很低，如果能夠把部分數據或業務邏輯轉移到內存緩存，效率會有極大地提升。
可拓展：當然如果我們想支持更多用戶，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峯。
4、架構方案
一般的秒殺系統架構
設計思路
將請求攔截在系統上游，降低下游壓力：秒殺系統特點是併發量極大，但實際秒殺成功的請求數量卻很少，所以如果不在前端攔截很可能造成數據庫讀寫鎖衝突，甚至導致死鎖，最終請求超時
充分利用緩存：利用緩存預減庫存，攔截掉大部分請求
消息隊列：這是一個異步處理過程，後臺業務根據自己的處理能力，從消息隊列中主動的拉取請求消息進行業務處理
前端方案
頁面靜態化：將活動頁面上的所有可以靜態的元素全部靜態化，並儘量減少動態元素。通過CDN來抗峯值。
禁止重複提交：用戶提交之後按鈕置灰，禁止重複提交
用戶限流：在某一時間段內只允許用戶提交一次請求，比如可以採取IP限流
後端方案
限制uid（UserID）訪問頻率：我們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它插件，在服務端控制層需要針對同一個訪問uid，限制訪問頻率。
上面只攔截了一部分訪問請求，當秒殺的用戶量很大時，即使每個用戶只有一個請求，到服務層的請求數量還是很大。比如我們有100W用戶同時搶100臺手機，服務層併發請求壓力至少爲100W。
1、把需要秒殺的商品的主要信息以及庫存初始化到redis緩存中
2、做請求合法性的校驗（比如是否登錄），如果請求非法，直接給前端返回錯誤碼，進行相應的提示
3、進行內存標識的判斷(true 已經秒殺結束，false 未秒殺結束)，如果內存標識爲true，直接返回秒殺結束
4、decr 進行預減庫存操作，判斷，如果decr後庫存量小於0，則把內存標記置爲true(已經秒殺結束)，且返回秒殺結束
5、判斷是否已經秒殺到了，防止重複秒殺，如果重複秒殺，直接返回重複秒殺的錯誤碼
6、發送秒殺到的MQ消息給相應的業務端進行處理，並給用戶端返回排隊中，如果客戶端收到排隊中的消息，則自動進行輪詢查詢，直到返回秒殺成功或者秒殺失敗爲止
7、相應的業務端進行處理：真正處理秒殺的業務端，再次進行校驗（比如秒殺是否結束，庫存是否充足等）、將用戶和商品id作爲key存入redis來標識該用戶秒殺該商品成功(上述的第5步會用到)、減庫存、生成秒殺訂單、返回秒殺成功
注意：就算請求走到了真正處理業務的這一端，也有可能秒殺失敗，比如秒殺結束，庫存不足，真正減庫存失敗，秒殺單生成失敗等等，一旦失敗，則返回秒殺結束
優化：將秒殺接口隱藏：用戶點擊秒殺按鈕的時候，根據用戶id生成唯一的加密串存入緩存並返回給客戶端，然後客戶端再次請求的時候帶着加密串過來，後端進行校驗是否合法，若不合法，直接返回請求非法；
限制某個接口的訪問頻率：可以用攔截器配合自定義註解來實現，這麼做可以和具體的業務分離減少入侵，使用起來也非常方便
數據庫層
數據庫層是最脆弱的一層，一般在應用設計時在上游就需要把請求攔截掉，數據庫層只承擔“能力範圍內”的訪問請求。所以，上面通過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂
爲防止秒殺出現負數訂單數大於真正的庫存數，所以在真正減庫存，update庫存的時候應該加上where 庫存>0，而且需要給秒殺訂單表加上用戶id和商品id聯合的唯一索引