【高并發解決方案】5、如何設計一個秒殺系統

什麼是秒殺

秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對于電商網站中一些稀缺或者特價商品，電商網站一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，并且會在約定的時間點同時在秒殺頁面進行搶購。

秒殺系統場景特點

• 秒殺時大量使用者會在同一時間同時進行搶購，網站瞬時通路流量激增。
• 秒殺一般是通路請求數量遠遠大于庫存數量，隻有少部分使用者能夠秒殺成功。
• 秒殺業務流程比較簡單，一般就是下訂單減庫存。

秒殺架構設計理念

限流： 鑒于隻有少部分使用者能夠秒殺成功，是以要限制大部分流量，隻允許少部分流量進入服務後端。

削峰：對于秒殺系統瞬時會有大量使用者湧入，是以在搶購一開始會有很高的瞬間峰值。高峰值流量是壓垮系統很重要的原因，是以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實作削峰的常用的方法有利用緩存和消息中間件等技術。

異步處理：秒殺系統是一個高并發系統，采用異步處理模式可以極大地提高系統并發量，其實異步處理就是削峰的一種實作方式。

記憶體緩存：秒殺系統最大的瓶頸一般都是資料庫讀寫，由于資料庫讀寫屬于磁盤IO，性能很低，如果能夠把部分資料或業務邏輯轉移到記憶體緩存，效率會有極大地提升。

可拓展：當然如果我們想支援更多使用者，更大的并發，最好就将系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峰。

架構方案

一般秒殺系統架構

設計思路

将請求攔截在系統上遊，降低下遊壓力：秒殺系統特點是并發量極大，但實際秒殺成功的請求數量卻很少，是以如果不在前端攔截很可能造成資料庫讀寫鎖沖突，甚至導緻死鎖，最終請求逾時。 

充分利用緩存：利用緩存可極大提高系統讀寫速度。 

消息隊列：消息隊列可以削峰，将攔截大量并發請求，這也是一個異步處理過程，背景業務根據自己的處理能力，從消息隊列中主動的拉取請求消息進行業務處理。

前端方案

浏覽器端(js)：

頁面靜态化：将活動頁面上的所有可以靜态的元素全部靜态化，并盡量減少動态元素。通過CDN來抗峰值。 

禁止重複送出：使用者送出之後按鈕置灰，禁止重複送出 

使用者限流：在某一時間段内隻允許使用者送出一次請求，比如可以采取IP限流

後端方案

服務端控制器層(網關層)

限制uid（UserID）通路頻率：我們上面攔截了浏覽器通路的請求，但針對某些惡意攻擊或其它插件，在服務端控制層需要針對同一個通路uid，限制通路頻率。

服務層

上面隻攔截了一部分通路請求，當秒殺的使用者量很大時，即使每個使用者隻有一個請求，到服務層的請求數量還是很大。比如我們有100W使用者同時搶100台手機，服務層并發請求壓力至少為100W。

1. 采用消息隊列緩存請求：既然服務層知道庫存隻有100台手機，那完全沒有必要把100W個請求都傳遞到資料庫啊，那麼可以先把這些請求都寫到消息隊列緩存一下，資料庫層訂閱消息減庫存，減庫存成功的請求傳回秒殺成功，失敗的傳回秒殺結束。
2. 利用緩存應對讀請求：對類似于12306等購票業務，是典型的讀多寫少業務，大部分請求是查詢請求，是以可以利用緩存分擔資料庫壓力。
3. 利用緩存應對寫請求：緩存也是可以應對寫請求的，比如我們就可以把資料庫中的庫存資料轉移到Redis緩存中，所有減庫存操作都在Redis中進行，然後再通過背景程序把Redis中的使用者秒殺請求同步到資料庫中。

資料庫層

資料庫層是最脆弱的一層，一般在應用設計時在上遊就需要把請求攔截掉，資料庫層隻承擔“能力範圍内”的通路請求。是以，上面通過在服務層引入隊列和緩存，讓最底層的資料庫高枕無憂。

案例：利用消息中間件和緩存實作簡單的秒殺系統

Redis是一個分布式緩存系統，支援多種資料結構，我們可以利用Redis輕松實作一個強大的秒殺系統。

我們可以采用Redis 最簡單的key-value資料結構，用一個原子類型的變量值(AtomicInteger)作為key，把使用者id作為value，庫存數量便是原子變量的最大值。對于每個使用者的秒殺，我們使用 RPUSH key value插入秒殺請求， 當插入的秒殺請求數達到上限時，停止所有後續插入。

然後我們可以在台啟動多個工作線程，使用 LPOP key 讀取秒殺成功者的使用者id，然後再操作資料庫做最終的下訂單減庫存操作。