• 背景

• 秒殺的特征

• 秒殺系統(tǒng)

背景

秒殺活動(dòng)是絕大部分電商選擇的低價(jià)促銷、推廣品牌的方式。不僅可以給平臺(tái)帶來(lái)用戶量，還可以提高平臺(tái)知名度。

一個(gè)好的秒殺系統(tǒng)，可以提高平臺(tái)系統(tǒng)的穩(wěn)定性和公平性，獲得更好的用戶體驗(yàn)，提升平臺(tái)的口碑，從而提升秒殺活動(dòng)的最大價(jià)值。

本文討論云數(shù)據(jù)庫(kù) Redis 版緩存設(shè)計(jì)高并發(fā)的秒殺系統(tǒng)。

秒殺的特征

秒殺活動(dòng)對(duì)稀缺或者特價(jià)的商品進(jìn)行定時(shí)定量售賣，吸引成大量的消費(fèi)者進(jìn)行搶購(gòu)，但又只有少部分消費(fèi)者可以下單成功。因此，秒殺活動(dòng)將在較短時(shí)間內(nèi)產(chǎn)生比平時(shí)大數(shù)十倍，上百倍的頁(yè)面訪問(wèn)流量和下單請(qǐng)求流量。

秒殺活動(dòng)可以分為3個(gè)階段：

• 秒殺前：用戶不斷刷新商品詳情頁(yè)，頁(yè)面請(qǐng)求達(dá)到瞬時(shí)峰值。

• 秒殺開(kāi)始：用戶點(diǎn)擊秒殺按鈕，下單請(qǐng)求達(dá)到瞬時(shí)峰值。

• 秒殺后：一部分成功下單的用戶不斷刷新訂單或者產(chǎn)生退單操作，大部分用戶繼續(xù)刷新商品詳情頁(yè)等待退單機(jī)會(huì)。

消費(fèi)者提交訂單，一般做法是利用數(shù)據(jù)庫(kù)的行級(jí)鎖，只有搶到鎖的請(qǐng)求可以進(jìn)行庫(kù)存查詢和下單操作。

但是在高并發(fā)的情況下，數(shù)據(jù)庫(kù)無(wú)法承擔(dān)如此大的請(qǐng)求，往往會(huì)使整個(gè)服務(wù) blocked，在消費(fèi)者看來(lái)就是服務(wù)器宕機(jī)。

秒殺系統(tǒng)

秒殺系統(tǒng)的流量雖然很高，但是實(shí)際有效流量是十分有限的。利用系統(tǒng)的層次結(jié)構(gòu)，在每個(gè)階段提前校驗(yàn)，攔截?zé)o效流量，可以減少大量無(wú)效的流量涌入數(shù)據(jù)庫(kù)。

利用瀏覽器緩存和 CDN 抗壓靜態(tài)頁(yè)面流量

秒殺前，用戶不斷刷新商品詳情頁(yè)，造成大量的頁(yè)面請(qǐng)求。所以，我們需要把秒殺商品詳情頁(yè)與普通的商品詳情頁(yè)分開(kāi)。

對(duì)于秒殺商品詳情頁(yè)盡量將能靜態(tài)化的元素靜態(tài)化處理，除了秒殺按鈕需要服務(wù)端進(jìn)行動(dòng)態(tài)判斷，其他的靜態(tài)數(shù)據(jù)可以緩存在瀏覽器和 CDN 上。這樣，秒殺前刷新頁(yè)面導(dǎo)致的流量進(jìn)入服務(wù)端的流量只有很小的一部分。

利用讀寫(xiě)分離 Redis 緩存攔截流量

CDN 是第一級(jí)流量攔截，第二級(jí)流量攔截我們使用支持讀寫(xiě)分離的 Redis。在這一階段我們主要讀取數(shù)據(jù)，讀寫(xiě)分離 Redis 能支持高達(dá)60萬(wàn)以上 qps，完全可以支持需求。

首先通過(guò)數(shù)據(jù)控制模塊，提前將秒殺商品緩存到讀寫(xiě)分離 Redis，并設(shè)置秒殺開(kāi)始標(biāo)記如下：

"goodsId_count": 100 //總數(shù)
"goodsId_start": 0   //開(kāi)始標(biāo)記
"goodsId_access": 0  //接受下單數(shù)

1. 秒殺開(kāi)始前，服務(wù)集群讀取 goodsId_Start 為 0，直接返回未開(kāi)始。

2. 數(shù)據(jù)控制模塊將 goodsId_start 改為1，標(biāo)志秒殺開(kāi)始。

3. 服務(wù)集群緩存開(kāi)始標(biāo)記位并開(kāi)始接受請(qǐng)求，并記錄到 redis 中 goodsId_access，商品剩余數(shù)量為(goodsId_count - goodsId_access)。

4. 當(dāng)接受下單數(shù)達(dá)到 goodsId_count 后，繼續(xù)攔截所有請(qǐng)求，商品剩余數(shù)量為 0。

可以看出，最后成功參與下單的請(qǐng)求只有少部分可以被接受。在高并發(fā)的情況下，允許稍微多的流量進(jìn)入。因此可以控制接受下單數(shù)的比例。

利用主從版 Redis 緩存加速庫(kù)存扣量

成功參與下單后，進(jìn)入下層服務(wù)，開(kāi)始進(jìn)行訂單信息校驗(yàn)，庫(kù)存扣量。

為了避免直接訪問(wèn)數(shù)據(jù)庫(kù)，我們使用主從版 Redis 來(lái)進(jìn)行庫(kù)存扣量，主從版 Redis 提供10萬(wàn)級(jí)別的 QPS。使用 Redis 來(lái)優(yōu)化庫(kù)存查詢，提前攔截秒殺失敗的請(qǐng)求，將大大提高系統(tǒng)的整體吞吐量。

通過(guò)數(shù)據(jù)控制模塊提前將庫(kù)存存入 Redis，將每個(gè)秒殺商品在 Redis 中用一個(gè) hash 結(jié)構(gòu)表示。

"goodsId" : {
    "Total": 100
    "Booked": 100
}

扣量時(shí)，服務(wù)器通過(guò)請(qǐng)求 Redis 獲取下單資格，通過(guò)以下 lua 腳本實(shí)現(xiàn)，由于 Redis 是單線程模型，lua 可以保證多個(gè)命令的原子性。

local n = tonumber(ARGV[1])
if not n  or n == 0 then
    return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
    return 0
end
if blocked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    return n;
end
return 0

先使用SCRIPT LOAD將 lua 腳本提前緩存在 Redis，然后調(diào)用EVALSHA調(diào)用腳本，比直接調(diào)用EVAL節(jié)省網(wǎng)絡(luò)帶寬：

redis 127.0.0.1:6379>SCRIPT LOAD "lua code"
"438dd755f3fe0d32771753eb57f075b18fed7716"
redis 127.0.0.1:6379>EVAL 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1

秒殺服務(wù)通過(guò)判斷 Redis 是否返回?fù)屬?gòu)個(gè)數(shù) n，即可知道此次請(qǐng)求是否扣量成功。

使用主從版 Redis 實(shí)現(xiàn)簡(jiǎn)單的消息隊(duì)列異步下單入庫(kù)

扣量完成后，需要進(jìn)行訂單入庫(kù)。如果商品數(shù)量較少的時(shí)候，直接操作數(shù)據(jù)庫(kù)即可。

如果秒殺的商品是1萬(wàn)，甚至10萬(wàn)級(jí)別，那數(shù)據(jù)庫(kù)鎖沖突將帶來(lái)很大的性能瓶頸。

因此，利用消息隊(duì)列組件，當(dāng)秒殺服務(wù)將訂單信息寫(xiě)入消息隊(duì)列后，即可認(rèn)為下單完成，避免直接操作數(shù)據(jù)庫(kù)。

1. 消息隊(duì)列組件依然可以使用 Redis 實(shí)現(xiàn)，在 R2 中用 list 數(shù)據(jù)結(jié)構(gòu)表示。

    orderList {
        [0] = {訂單內(nèi)容}
        [1] = {訂單內(nèi)容}
        [2] = {訂單內(nèi)容}
        ...
    }
   

2. 將訂單內(nèi)容寫(xiě)入 Redis:

   LPUSH orderList {訂單內(nèi)容}
   

3. 異步下單模塊從 Redis 中順序獲取訂單信息，并將訂單寫(xiě)入數(shù)據(jù)庫(kù)。

    BRPOP orderList 0
   

通過(guò)使用 Redis 作為消息隊(duì)列，異步處理訂單入庫(kù)，有效的提高了用戶的下單完成速度。

數(shù)據(jù)控制模塊管理秒殺數(shù)據(jù)同步

最開(kāi)始，利用讀寫(xiě)分離 Redis 進(jìn)行流量限制，只讓部分流量進(jìn)入下單。對(duì)于下單檢驗(yàn)失敗和退單等情況，需要讓更多的流量進(jìn)來(lái)。

因此，數(shù)據(jù)控制模塊需要定時(shí)將數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行一定的計(jì)算，同步到主從版 Redis，同時(shí)再同步到讀寫(xiě)分離的 Redis，讓更多的流量進(jìn)來(lái)。

End

作者：AlibabaCloud , 本文版權(quán)歸作者所有

https://github.com/AlibabaCloudDocs

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝