什麼是秒殺
秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對於電商網站中一些稀缺或者特價商品，電商網站一般會在約定時間點對其進行限量銷售，因爲這些商品的特殊性，會吸引大量用戶前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。
秒殺系統場景特點
- 秒殺時大量用戶會在同一時間同時進行搶購，網站瞬時訪問流量激增。
- 秒殺一般是訪問請求數量遠遠大於庫存數量，只有少部分用戶能夠秒殺成功。
- 秒殺業務流程比較簡單，一般就是下訂單減庫存。
秒殺的業務場景跟其他業務場景不一樣，主要是秒殺的瞬間，併發非常大，如何針對此大併發是我們需要取解決的。秒殺業務,是典型的短時大量突發訪問。
秒殺架構設計理念
- 限流： 鑑於只有少部分用戶能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進入服務後端。
- 削峯：對於秒殺系統瞬時會有大量用戶湧入，所以在搶購一開始會有很高的瞬間峯值。高峯值流量是壓垮系統很重要的原因，所以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實現削峯的常用的方法有利用緩存和消息中間件等技術。
- 異步處理：秒殺系統是一個高併發系統，採用異步處理模式可以極大地提高系統併發量，其實異步處理就是削峯的一種實現方式。
- 內存緩存：秒殺系統最大的瓶頸一般都是數據庫讀寫，由於數據庫讀寫屬於磁盤IO，性能很低，如果能夠把部分數據或業務邏輯轉移到內存緩存，效率會有極大地提升。
- 可拓展：當然如果我們想支持更多用戶，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峯。
秒殺系統架構設計思路
- 將請求攔截在系統上游，降低下游壓力：秒殺系統特點是併發量極大，但實際秒殺成功的請求數量卻很少，所以如果不在前端攔截很可能造成數據庫讀寫鎖衝突，最終請求超時。
- 利用緩存：利用緩存可極大提高系統讀寫速度。
- 消息隊列：消息隊列可以削峯，將攔截大量併發請求，這也是一個異步處理過程，後臺業務根據自己的處理能力，從消息隊列中主動的拉取請求消息進行業務處理。
前端方案
頁面靜態化：將活動頁面上的所有可以靜態的元素全部靜態化，並儘量減少動態元素。通過CDN來抗峯值。
禁止重複提交：用戶提交之後按鈕置灰，禁止重複提交
用戶限流：在某一時間段內只允許用戶提交一次請求，比如可以採取IP限流
後端方案
限制uid（UserID）訪問頻率：我們上面攔截了瀏覽器訪問的請求，但針對某些惡意攻擊或其它插件，在服務端控制層需要針對同一個訪問uid，限制訪問頻率。
上面只攔截了一部分訪問請求，當秒殺的用戶量很大時，即使每個用戶只有一個請求，到服務層的請求數量還是很大。比如我們有10W用戶同時搶10臺手機，服務層併發請求壓力至少爲10W。
採用消息隊列緩存請求：既然服務層知道庫存只有10臺手機，那完全沒有必要把10W個請求都傳遞到數據庫啊，那麼可以先把這些請求都寫到消息隊列緩存一下，數據庫層訂閱消息減庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束。
利用緩存應對讀請求：對類似於12306等購票業務和商品秒殺場景，是典型的讀多寫少業務，大部分請求是查詢請求，所以可以利用緩存分擔數據庫壓力。
利用緩存應對寫請求：緩存也是可以應對寫請求的，比如我們就可以把數據庫中的庫存數據轉移到Redis緩存中，所有減庫存操作都在Redis中進行，然後再通過後臺進程把Redis中的用戶秒殺請求同步到數據庫中。
數據庫層
數據庫層是最脆弱的一層，一般在應用設計時在上游就需要把請求攔截掉，數據庫層只承擔“能力範圍內”的訪問請求。所以，上面通過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂。
使用技術
- 前端：Thymeleaf、Bootstrap、JQuery
- 後端：SpringBoot、Mybatis
- 中間件：RabbitMQ、Redis、Druid
注：Thymeleaf其實是一個服務端的模板；RabbitMQ實現異步下單；使用redis做緩存（相比較於Memcached有比較多的一些優點，Redis可以做持久化）；druid：阿里巴巴開發的連接池，好處：可以做監控，監控連接池裏面的連接、最大連接多少、最大併發多少、最長的時間等特性。
主要項目技術描述
- 使用分佈式Seesion，讓多臺服務器可以響應。
- 使用redis做緩存提高訪問速度和併發量，減少數據庫壓力。
- 使用頁面靜態化，緩存頁面至瀏覽器，前後端分離降低服務器壓力。
- 使用消息隊列完成異步下單，提升用戶體驗，削峯和降流。
- 安全性優化：雙重md5密碼校驗，秒殺接口地址的隱藏，接口限流防刷，數 學公式驗證碼。
效果展示
秒殺場景秒殺商品列表：
具體商品秒殺頁面，秒殺倒計時：
秒殺進行中頁面：
秒殺成功頁面：
限制一定時間段裏面的秒殺次數：
不可重複秒殺：
