背景

秒殺活動是絕大部分電商選擇的低價促銷、推廣品牌的方式。不僅可以給平臺帶來使用者量，還可以提高平臺知名度。一個好的秒殺系統，可以提高平臺系統的穩定性和公平性，獲得更好的使用者體驗，提升平臺的口碑，從而提升秒殺活動的最大價值。

本文討論雲資料庫 Redis 版快取設計高併發的秒殺系統。

秒殺的特徵

秒殺活動對稀缺或者特價的商品進行定時定量售賣，吸引成大量的消費者進行搶購，但又只有少部分消費者可以下單成功。因此，秒殺活動將在較短時間內產生比平時大數十倍，上百倍的頁面訪問流量和下單請求流量。

秒殺活動可以分為3個階段：

• 秒殺前：使用者不斷重新整理商品詳情頁，頁面請求達到瞬時峰值。

• 秒殺開始：使用者點選秒殺按鈕，下單請求達到瞬時峰值。

• 秒殺後：一部分成功下單的使用者不斷重新整理訂單或者產生退單操作，大部分使用者繼續重新整理商品詳情頁等待退單機會。

消費者提交訂單，一般做法是利用資料庫的行級鎖，只有搶到鎖的請求可以進行庫存查詢和下單操作。但是在高併發的情況下，資料庫無法承擔如此大的請求，往往會使整個服務 blocked，在消費者看來就是伺服器宕機。

秒殺系統

秒殺系統的流量雖然很高，但是實際有效流量是十分有限的。利用系統的層次結構，在每個階段提前校驗，攔截無效流量，可以減少大量無效的流量湧入資料庫。

利用瀏覽器快取和 CDN 抗壓靜態頁面流量

秒殺前，使用者不斷重新整理商品詳情頁，造成大量的頁面請求。所以，我們需要把秒殺商品詳情頁與普通的商品詳情頁分開。對於秒殺商品詳情頁儘量將能靜態化的元素靜態化處理，除了秒殺按鈕需要服務端進行動態判斷，其他的靜態資料可以快取在瀏覽器和 CDN 上。這樣，秒殺前重新整理頁面導致的流量進入服務端的流量只有很小的一部分。

利用讀寫分離 Redis 快取攔截流量

CDN 是第一級流量攔截，第二級流量攔截我們使用支援讀寫分離的 Redis。在這一階段我們主要讀取資料，讀寫分離 Redis 能支援高大60萬以上 qps 的，完全可以支援需求。

首先通過資料控制模組，提前將秒殺商品快取到讀寫分離 Redis，並設定秒殺開始標記如下：

1. "goodsId_count":100//總數
2. "goodsId_start":0//開始標記
3. "goodsId_access":0//接受下單數

1. 秒殺開始前，服務叢集讀取 goodsId_Start 為 0，直接返回未開始。

2. 資料控制模組將 goodsId_start 改為1，標誌秒殺開始。

3. 服務叢集快取開始標記位並開始接受請求，並記錄到 redis 中 goodsId_access，商品剩餘數量為(goodsId_count - goodsId_access)。

4. 當接受下單數達到 goodsId_count 後，繼續攔截所有請求，商品剩餘數量為 0。

可以看出，最後成功參與下單的請求只有少部分可以被接受。在高併發的情況下，允許稍微多的流量進入。因此可以控制接受下單數的比例。

利用主從版 Redis 快取加速庫存扣量

成功參與下單後，進入下層服務，開始進行訂單資訊校驗，庫存扣量。為了避免直接訪問資料庫，我們使用主從版 Redis 來進行庫存扣量，主從版 Redis 提供10萬級別的 QPS。使用 Redis 來優化庫存查詢，提前攔截秒殺失敗的請求，將大大提高系統的整體吞吐量。

通過資料控制模組提前將庫存存入 Redis，將每個秒殺商品在 Redis 中用一個 hash 結構表示。

1. "goodsId":{
2. "Total":100
3. "Booked":100
4. }

扣量時，伺服器通過請求 Redis 獲取下單資格，通過以下 lua 指令碼實現，由於 Redis 是單執行緒模型，lua 可以保證多個命令的原子性。

1. local n = tonumber(ARGV[1])
2. ifnot n or n ==0then
3. return0
4. end
5. local vals = redis.call("HMGET", KEYS[1],"Total","Booked");
6. local total = tonumber(vals[1])
7. local blocked = tonumber(vals[2])
8. ifnot total ornot blocked then
9. return0
10. end
11. if blocked + n <= total then
12. redis.call("HINCRBY", KEYS[1],"Booked", n)
13. return n;
14. end
15. return0

先使用SCRIPT LOAD將 lua 指令碼提前快取在 Redis，然後呼叫EVALSHA呼叫指令碼，比直接呼叫EVAL節省網路頻寬：

1. redis 127.0.0.1:6379>SCRIPT LOAD "lua code"
2. "438dd755f3fe0d32771753eb57f075b18fed7716"
3. redis 127.0.0.1:6379>EVAL 438dd755f3fe0d32771753eb57f075b18fed77161 goodsId 1

秒殺服務通過判斷 Redis 是否返回搶購個數 n，即可知道此次請求是否扣量成功。

使用主從版 Redis 實現簡單的訊息佇列非同步下單入庫

扣量完成後，需要進行訂單入庫。如果商品數量較少的時候，直接操作資料庫即可。如果秒殺的商品是1萬，甚至10萬級別，那資料庫鎖衝突將帶來很大的效能瓶頸。因此，利用訊息佇列元件，當秒殺服務將訂單資訊寫入訊息佇列後，即可認為下單完成，避免直接操作資料庫。

1. 訊息佇列元件依然可以使用 Redis 實現，在 R2 中用 list 資料結構表示。

   1. orderList {
   2. [0]={訂單內容}
   3. [1]={訂單內容}
   4. [2]={訂單內容}
   5. ...
   6. }

2. 將訂單內容寫入 Redis:

   1. LPUSH orderList {訂單內容}

3. 非同步下單模組從 Redis 中順序獲取訂單資訊，並將訂單寫入資料庫。

   1. BRPOP orderList 0

通過使用 Redis 作為訊息佇列，非同步處理訂單入庫，有效的提高了使用者的下單完成速度。

資料控制模組管理秒殺資料同步

最開始，利用讀寫分離 Redis 進行流量限制，只讓部分流量進入下單。對於下單檢驗失敗和退單等情況，需要讓更多的流量進來。因此，資料控制模組需要定時將資料庫中的資料進行一定的計算，同步到主從版 Redis，同時再同步到讀寫分離的 Redis，讓更多的流量進來。