假如你是一名架構(gòu)師，你會如何設(shè)計一個秒殺系統(tǒng)？這篇文章，我們就來聊一聊。

1. 什么是秒殺？

所謂秒殺，就是在同一個時刻有大量的客戶端請求爭搶同一個商品并完成交易的過程，瞬時會產(chǎn)生大量的并發(fā)讀和并發(fā)寫。

秒殺系統(tǒng)本質(zhì)上就是一個滿足高并發(fā)、高性能和高可用的分布式系統(tǒng)，下面給出一張下單交互概要圖：

2. 秒殺系統(tǒng)的特點

高性能

秒殺涉及大量的并發(fā)讀和并發(fā)寫，因此秒系統(tǒng)必須能支持高并發(fā)訪問，而且RT(響應(yīng)時間)需要在一定的范圍內(nèi)，通常是200ms

一致性

秒殺系統(tǒng)中通常會使用緩存，如何保證緩存和數(shù)據(jù)庫中庫存數(shù)據(jù)的一致性，保證商品庫存的準(zhǔn)確性

高可用

秒殺系統(tǒng)會在瞬間收到大量的讀寫操作，如何能保證服務(wù)能穩(wěn)定的運行，設(shè)計系統(tǒng)時是否考慮到系統(tǒng)容災(zāi)問題，保證服務(wù)的高可用

可擴展性

當(dāng)服務(wù)達到瓶頸時，如何能實現(xiàn)快速擴容。

3. 如何設(shè)計秒殺系統(tǒng)

從在上述秒殺概要圖中，我們可以知道，整個秒殺流程需要從前端和后端2個核心部分進行，因此我們就從這 2個部分來講解秒殺系統(tǒng)是如何設(shè)計的。

3.1 前端秒殺設(shè)計

服務(wù)高可用

前端是秒殺的入口，用戶首先是到前端界面進行商品瀏覽，然后加購自己想要的商品進行下單付款操作。 所以，前端服務(wù)一定要保證高可用，要不然秒殺的入口都沒有了，談何秒殺。

頁面靜態(tài)化

前端數(shù)據(jù)源動靜分離，靜態(tài)的數(shù)據(jù)可以放到CDN，前端從CDN獲取，動態(tài)的數(shù)據(jù)放到服務(wù)器。 靜態(tài)數(shù)據(jù)，比如商品的詳情信息，圖片等；動態(tài)數(shù)據(jù)，商品的數(shù)量，價格等。 比如：可以通過Url地址作為key來存儲靜態(tài)數(shù)據(jù)

控制對服務(wù)器請求的頻率

控制對服務(wù)器請求頻率能在一定程度上緩解服務(wù)器的壓力，限頻的方式有很多， 比如 秒殺按鈕點擊后置灰一定的時長后才能再次點擊， 前端 答題正確后才向服務(wù)器發(fā)起請求，前端將請求加入隊列進行排隊，當(dāng)有多個秒殺活動時，可以分時段進行，這些方式都是無損的。

控制對服務(wù)器請求參數(shù)的大小

因為秒殺期間，瞬時會有大量的請求涌向服務(wù)器，所以前端和服務(wù)器的數(shù)據(jù)交互要盡量的少，減少網(wǎng)絡(luò)傳輸以及編解碼的開銷

限流，降級

當(dāng)下游服務(wù)器達到瓶頸時，可以采用前端限流方式，降低對服務(wù)器的TPS和QPS。但是當(dāng)客戶端比較分散時，限流閾值的設(shè)置是一個比較大的挑戰(zhàn)：閾值設(shè)的太小，會導(dǎo)致服務(wù)端沒有達到瓶頸時客戶端已經(jīng)被限制；設(shè)的太大，則起不到限制的作用。

3.2 后端秒殺設(shè)計

服務(wù)高可用

后端是處理請求的核心服務(wù)，所以必須做好高可用部署，容災(zāi)設(shè)計(異地多活)

降級，限流，拒絕服務(wù)

降級，就是當(dāng)系統(tǒng)的容量達到一定程度時，限制或者關(guān)閉系統(tǒng)的某些非核心功能，從而把有限的資源保留給更核心的業(yè)務(wù)。所以降級一般需要前后端配合執(zhí)行，可以通過開關(guān)系統(tǒng)來實現(xiàn)。比如： 當(dāng)QPS達到一個閾值時，可是設(shè)置開關(guān)，將原來分頁查50條數(shù)據(jù)，變成查10條，減少一次交互的數(shù)據(jù)量。

限流，就是當(dāng)系統(tǒng)容量達到瓶頸時，通過限制一部分流量來保護系統(tǒng)，限流可以是接口級別，服務(wù)器級別，iP級別等等，此處的限流是有損操作，限流的閾值一般可以根據(jù)壓測結(jié)果來設(shè)置

直接拒絕服務(wù)，如果限流還不能解決問題，那就直接拒絕服務(wù)以求自保，這也是最差的一種兜底情況。

獨立部署秒殺服務(wù)

秒殺系統(tǒng)和普通的售賣有一定的差異點，秒殺一般是持續(xù)時間短，并發(fā)量高，所以為了不影響正常的售賣，可以單獨部署一套秒殺服務(wù)，在物理級別進行隔離，也適合服務(wù)端靈活伸縮容以及做一些特殊的個性化處理。 有條件的團隊可以實施。

流量削峰當(dāng)服務(wù)流量過大時，可以將請求存入MQ消息中間件進行削峰處理，客戶端可以采用輪詢的方式向服務(wù)器獲取結(jié)果(服務(wù)器會受到很多結(jié)果查詢的請求)，或者服務(wù)主動push結(jié)果給客戶端(服務(wù)需要保留很多和客戶端的長鏈接)，2種方式各有優(yōu)劣，一般生產(chǎn)上輪詢查詢結(jié)果用的比較多。

熱點數(shù)據(jù)探測

很多時候，一個商品不屬于秒殺，但是很多用戶購買，可能會成為熱點數(shù)據(jù)，請求量不亞于秒殺，所以網(wǎng)關(guān)需要有熱點數(shù)據(jù)探測的功能，實現(xiàn)的方式有很多，比如：統(tǒng)計客戶端的請求數(shù)

增加緩存

秒殺一般遵從讀多寫少的28法則，所以可以在服務(wù)端增加緩存應(yīng)對高并發(fā)讀。緩存可以設(shè)置2層，第一層是本地緩存，可以使用Google guava的緩存框架，失效時間一般可以秒級別，本地緩存是屬于jvm級別的，每次失效后可以從redis緩存中加載，redis緩存要特別注意緩存失效，緩存擊穿，緩存雪崩的問題。

緩存擊穿：緩存中不存在，數(shù)據(jù)庫存在，這樣就會導(dǎo)致請求直接到達數(shù)據(jù)庫，當(dāng)請求量比較大時，可能直接把數(shù)據(jù)庫打垮。解決方法：

1. 可以考慮緩存永遠(yuǎn)不過期
2. 同步返回null，異步加鎖查詢數(shù)據(jù)庫，更新緩存

緩存穿透：請求的數(shù)據(jù)在緩存和數(shù)據(jù)庫中都不存在，解決辦法：

1. 業(yè)務(wù)層進行合法校驗，攔截大部分不合法的請求
2. 使用布隆過濾器，針對一個或者多個維度，把可能存在的數(shù)據(jù)值hash到bitmap中，bitmap中不存在則該數(shù)據(jù)一定不存在，bitmap中存該數(shù)據(jù)可能存在
3. 對空的結(jié)果進行緩存，設(shè)置得較短過期時間，當(dāng)有數(shù)據(jù)庫變更時，必須同時刷新緩存，否則會導(dǎo)致不一致的問題存在

緩存雪崩：指緩存在同一時刻失效，請求都到數(shù)據(jù)庫上，解決的辦法：

1. 可以考慮緩存永遠(yuǎn)不過期
2. 失效時間盡量隨機，避免同時過期
3. 多級緩存，數(shù)據(jù)緩存到A和B，A設(shè)置過期時間，B不設(shè)置過期時間，如果A為空的時候去讀B，同時異步去更新緩存，需要同時更新兩個緩存

4. 如何保證不超賣？

秒殺一般都是優(yōu)惠售賣，所以庫存不超賣是前提，一般來說，防止超賣需要前后端配合，以下是幾種主要的實現(xiàn)方式：

4.1 庫存扣減方式

下單減庫存：買家下單后，扣減商品總庫存。下單減庫存是最簡單也是控制最精確的一種，下單時直接通過數(shù)據(jù)庫的事務(wù)機制控制商品庫存，一定不會出現(xiàn)超賣的情況。出現(xiàn)的問題： 惡意刷單，某些人下單后占用庫存不付款。

付款減庫存：買家付款之后，扣減商品總庫存。這種方式產(chǎn)生的問題是，庫存超賣。

預(yù)扣庫存：買家下單后，預(yù)扣庫存，在一定的時間內(nèi)未付款，庫存將會自動釋放。在買家付款前，需再次校驗庫存是否保留，如果沒有保留，則再次嘗試預(yù)扣；如果庫存不足則不允許繼續(xù)付款；如果預(yù)扣成功，則完成付款并實際地減去庫存。這種方式在生產(chǎn)上用的比較多。

4.2 服務(wù)端庫存處理

將庫存操作的邏輯放到lua腳本中，通過redis的單線程特性，保證Lua腳本執(zhí)行不會被打斷，從而保證庫存操作的原子性

5. 面試中如何回答

1. 先分析整個流程，然后再按前端和后端兩部分去分析
2. 前端用到什么技術(shù)，目的是什么，會出現(xiàn)什么問題，如何解決
3. 后端是側(cè)重點，可從業(yè)務(wù)架構(gòu)，技術(shù)架構(gòu)，分布式鎖，緩存，數(shù)據(jù)一致性，容災(zāi)來分析
4. 最后，做個總結(jié)

6. 總結(jié)

下面給出一張秒殺系統(tǒng)常用的架構(gòu)圖，百種業(yè)務(wù)百種架構(gòu)，一個秒殺系統(tǒng)看似簡單，其實包含了很多架構(gòu)的思想，從前端到后端，怎么全局把控，對于各個服務(wù)怎么去做高可用，高性能，可擴展保證。如何設(shè)計緩存，如何保證緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性，服務(wù)達到瓶頸時，如何做服務(wù)降級，限流。

圖片

一般我們遵從幾個原則：

1. 前后端交互的數(shù)據(jù)盡量少
2. 前端盡量控制對后端的無效請求
3. 服務(wù)之間的依賴盡量少
4. 請求路徑盡量短
5. 服務(wù)或者中間件不要有單點，要有容災(zāi)