實現商城商品秒殺分析

什麼是秒殺 秒殺場景通常會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對於網站中一些稀缺或者特價的產品，電商網站通常會在約定的時間對其進行限量銷售，由於這些產品的特殊性，會吸引大量用戶前來搶購，而且會在約定時間同時在秒殺頁面進行搶購。

設計思路 將請求攔截在系統上游，下降下流壓力;秒殺系統特色就是併發量極大，但實際秒殺成功的請求數量確不多，因此若是不在前端攔截可能形成數據庫讀寫鎖衝突，甚至致使死鎖，最終請求超時，甚至致使系統崩潰 充分利用緩存：利用緩存能夠極大提升系統讀寫速度 消息隊列：消息隊列能夠削峯，將攔截大量併發的請求，這也是一個異步處理過程，後臺業務根據本身的處理能力，從消息隊列中主動的拉取請求消息進行業務處理

前端方案 瀏覽器端（js）： 頁面靜態化：將活動頁面上的全部能夠靜態的元素所有靜態化，並儘可能減小動態元素，經過CDN來抗峯值 禁止重複提交：用戶提交以後按鈕置灰，禁止重複提交 用戶限流：在某一時間內只容許用戶提交一次請求，好比能夠採起IP限流

後端方案 服務器控制器層（網關層） 限制UID（userID）訪問頻率：咱們上面攔截了瀏覽器的訪問請求，但準對某些惡意請求和攻擊或者其餘插件，在服務器控制層要準對同一個uid，限制訪問頻率

服務層 上面只攔截了一部分請求，當秒殺的用戶量很是大時，即便每一個用戶只有一個請求，到服務層的請求數量仍是很大。好比咱們有100w用戶同時搶購100臺手機，服務層併發請求壓力至少爲100w。 1.採用消息隊列緩存請求：既然服務器層知道庫存只有100臺手機，那徹底沒有必要把100w個請求都傳遞到數據庫裏，那麼能夠先把這些請求都寫到消息隊列裏面緩存一下，數據庫層訂閱消息減小庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束 2.利用緩存應對讀請求：對相似12306等購票業務，是典型的讀多寫少業務，大部分請求時查詢請求，因此能夠利用緩存分擔數據庫壓力 3.利用緩存對寫請求：緩存也是能夠應對寫請求，好比咱們能夠把數據庫中庫存數據遷移到Redis緩存中，全部減庫存操做都在Redis中進行，而後經過後臺進程把Redis中的用戶秒殺請求同步到數據庫中

數據庫層 數據庫層是最脆弱的一層，通常在應用設計時在上游就須要把請求攔截，數據庫層只承擔「能力範圍內」的訪問請求。因此，上面經過在服務層引入的隊列和緩存，讓底層的數據庫高枕無憂