面試寶典系列-怎麼設計一個秒殺系統

方向：將請求儘可能攔截在系統上游

思路：限流和削峯

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

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

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

前端優化：

一、靜態資源緩存 

•  頁面靜態化
• CDN頁面緩存，也能夠用redis緩存渲染的頁面

 二、限流方法

• 使用驗證碼，防止機器人、爬蟲以及分散用戶請求
• 禁止重複提交 ：用戶提交以後按鈕置灰，禁止重複提交 

後端優化：

一、控制層方面入手

• 負載均衡 

        使用多個服務器併發處理請求，減少服務器壓力。

• 後端下發秒殺連接

        在秒殺開始前，前端不能獲得秒殺地址，防止提早獲取地址，模擬秒殺請求

• 限制同一個用戶id訪問頻率
• 服務降級

        基於令牌桶算法實現限流。令牌桶算法的原理是系統會以一個恆定的速度往桶裏放入令牌，而若是請求須要被處理，則須要先從桶裏獲取一個令牌，當桶裏沒有令牌可取時，則拒絕服務。

二、服務層

• 業務分離：秒殺業務系統和其餘業務分離，單獨放在高配服務器上。防止秒殺系統影響其餘業務系統

•  採用消息隊列緩存請求：將大流量請求寫到消息隊列緩存，利用服務器根據本身的處理能力主動到消息緩存隊列中抓取任務處理請求，數據庫層訂閱消息減庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束。

• 利用緩存應對讀請求：對於讀多寫少業務，大部分請求是查詢請求，因此能夠讀寫分離，利用緩存分擔數據庫壓力。

• 利用緩存應對寫請求：緩存也是能夠應對寫請求的，可把數據庫中的庫存數據轉移到Redis緩存中，全部減庫存操做都在Redis中進行，而後再經過後臺進程把Redis中的用戶秒殺請求同步到數據庫中。能夠將緩存和消息中間件 組合起來，緩存系統負責接收記錄用戶請求，消息中間件負責將緩存中的請求同步到數據庫。

 可使用redis的減操做，初始化庫存數，每個請求減1，而後將請求放在消息隊列中。若是返回結果小於0（爲了防止少賣現象，能夠多存放一些請求進消息隊列，即將閾值0改小），則認爲活動結束，返回客戶端。