秒殺系統設計面試

秒殺業務的特色就是多我的讀一個數據，難點就是讀寫衝突，鎖狀況特別的嚴重。 因此咱們儘可能不要讓請求落在數據庫上去，讓請求攔截在系統的上游。解決思路:

一、限流：屏蔽掉無用的流量，容許少部分流量流向後端。

二、削峯：瞬時大流量峯值容易壓垮系統。經常使用的消峯方法有異步處理、緩存和消息中間件等技術

• 異步處理：秒殺系統是一個高併發系統，採用異步處理模式能夠極大地提升系統併發量，其實異步處理就是削峯的一種實現方式。
• 緩存：秒殺系統自己是一個典型的讀多寫少的應用場景【一趟火車其實只有2000張票，200w我的來買，最多2000我的下單成功，其餘人都是查詢庫存，寫比例只有0.1%，讀比例佔99.9%】，很是適合使用緩存。
• 消息隊列：消息隊列能夠削峯，將攔截大量併發請求，這也是一個異步處理過程，後臺業務根據本身的處理能力，從消息隊列中主動的拉取請求消息進行業務處理。

前端優化

一、前端靜態資源緩存，頁面靜態化和使用cdn緩存或redis緩存

二、限流：1使用驗證碼防止機器人爬蟲腳本自動提交2禁止重複提交，用戶提交後按鈕置灰

後端優化

一、利用負載均衡，使用多個機器處理併發請求

二、秒殺開始前，前臺不能獲得秒殺地址，防止提早獲得秒殺地址，模擬秒殺請求

三、限制同一個用戶id訪問頻率

四、限制同一時間請求次數，達到請求上限時，隨機拒絕部分請求來保證服務可用

五、業務分離，將秒殺系統和其它業務分離，單獨放在高配機器上，防止影響其它業務系統

六、將秒殺請求放入到消息隊列隊列，後臺訂閱消息減庫存，檢測消息隊列長度，達到最大庫存不加消息隊列，直接返回秒殺失敗的消息

七、利用緩存應對讀請求，利用緩存減輕數據庫壓力

八、利用緩存應對寫請求，將數據庫的庫存數據轉到redis裏面，全部減庫存操做都在redis裏面進行，而後經過後臺進程把redis裏面的用戶秒殺請求同步到數據庫