秒殺活動架構(gòu)

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

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

所以秒殺系統(tǒng)中我們需要思考：

• “系統(tǒng)如何扛住高并發(fā)請求系統(tǒng)如何保證不超賣等問題”

對此我的解決思路是：

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

秒殺架構(gòu)圖

秒殺架構(gòu)圖如上。

客戶端

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

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

反向代理

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

Nginx也可以作為限流使用。Nginx可以控制單位時間內(nèi)的請求數(shù)，限制同一時間的連接數(shù)。

API網(wǎng)關

如果實際參與秒殺活動的用戶非常大，并發(fā)請求非常大。我們就需要在API網(wǎng)關這一層中進行限流，這里可以實現(xiàn)對單個Web節(jié)點實現(xiàn)每秒最大請求數(shù)限制。

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

緩存

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

隊列

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

關于限流

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

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

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

URI限流示例代碼：

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

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

在緩存中扣減庫存

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

示例代碼如下：

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

消費者創(chuàng)建訂單：

關于如何初始化庫存?

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

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

示例代碼如下：

總結(jié)

秒殺設計是典型的高并發(fā)系統(tǒng)，關于秒殺系統(tǒng)的設計，經(jīng)常會在面試中被問到。在設計秒殺系統(tǒng)時，我們需要考慮：

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