秒殺活動架構

秒殺活動是電商項目中常出現的活動。比如演唱會門票搶購，京東淘寶秒殺商品搶購。在搶購那一刻，會有大量用戶同時高并發的請求應用系統，可能會達到每秒幾萬、幾十萬的請求。如果系統無法處理這么高的請求，那么就會崩潰，從而導致系統不可用。

對于秒殺活動來說，要求系統不會出現壓力過大而崩潰的場景，并且不會出現超賣、少賣的情形。

所以秒殺系統中我們需要思考：

• “系統如何扛住高并發請求系統如何保證不超賣等問題”

對此我的解決思路是：

• “服務端中，使用緩存減少對數據庫訪問將請求流量攔截在上游，可以使用限流技術使用分布式隊列進行流量削峰，將并發串行化”

秒殺架構圖

秒殺架構圖如上。

客戶端

用戶發起請求的端口，目前電商項目秒殺活動主要客戶端有微信小程序、H5(瀏覽器)、各平臺app(比如Android、iOS、Windows)。我們可以在客戶端實現限流機制，這樣就可以避免用戶發送大量請求到服務端。

客戶端的限流可以控制按鈕的點擊頻率，比如對按鈕置灰。

反向代理

我們可以使用Nginx實現請求分流，通過負載均衡將請求均勻的分布到不同的Web節點中。

Nginx也可以作為限流使用。Nginx可以控制單位時間內的請求數，限制同一時間的連接數。

API網關

如果實際參與秒殺活動的用戶非常大，并發請求非常大。我們就需要在API網關這一層中進行限流，這里可以實現對單個Web節點實現每秒最大請求數限制。

我們也可以控制每個用戶的最大請求數，通過Redis記錄每個用戶的請求數。

緩存

在服務層業務中，為減少對數據庫的訪問，需要進行緩存設計，我們可以使用本地緩存，或者分布式緩存。

隊列

隊列主要是用來實現流量的削峰填谷，我們可以使用RocketMQ、Kafka等消息中間件作為分布式的隊列。

關于限流

秒殺系統中為什么需要限流?在秒殺活動中商品庫存是有限的，而請求的用戶數量遠遠大于商品庫存數量。大部分的用戶請求實際上是無法搶到商品的無效流量。所以這部分流量可以攔截在上游進行限流。

為了避免用戶采用腳本或者頻繁點擊發送大量請求，而導致其他用戶無法正常參加活動，我們也需要控制用戶每秒的請求量。

我們可從URI和用戶兩個方面實行限流。

URI限流示例代碼：

用戶維度的限流示例代碼：

我們獲取URI維度的限流器對象uriLimiter，和用戶維度的限流器對象userLimiter。如果tryAcquire()成功獲得許可，則請求通過，進入后續業務。否則直接報異常，前端界面作相應的友好提示。

在緩存中扣減庫存

使用Redis來存儲庫存數量，當用戶發起搶購請求時，先判斷Redis中的庫存是否可用。如果可用，將搶購請求放入分布式隊列中，采用異步方式處理后續操作，并完成下單。同時在Redis中作庫存扣減。

示例代碼如下：

先做庫存扣減并獲取扣減后的庫存數量，如果庫存數量大于或等于0，將訂單創建請求發送到mq。否則返回搶購失敗的信息。

消費者創建訂單：

關于如何初始化庫存?

在搶購活動開始前，有運營人員在后臺手動將商品庫存從數據庫同步到緩存中。庫存的扣減在緩存中進行扣減。

利用Redis單線程特性可以實現多線程下安全的庫存更新。如果查詢緩存中的值時，發現沒有，需要從數據庫中查詢，然后再同步到緩存中，這個過程需要加鎖。

示例代碼如下：

總結

秒殺設計是典型的高并發系統，關于秒殺系統的設計，經常會在面試中被問到。在設計秒殺系統時，我們需要考慮：

• “請求分流-通過負載均衡實現限流-采用漏斗算法(如guava的RateLimiter)，信號量Semaphore，Redis計數等實現Redis扣減庫存-減少對數據庫的訪問流量削峰-分布式隊列實現”