解讀秒殺業務：Redis如何助力高并發秒殺系統以及完美解決超賣問題

秒殺業務

在電商領域，存在著典型的秒殺業務場景，那何謂秒殺場景呢，簡單的來說就是一件商品的購買人數遠遠大于這件商品的庫存，而且這件商品在很短的時間內就會被搶購一空，比如每年的618、雙11大促，小米新品促銷等業務場景，就是典型的秒殺業務場景，

秒殺業務最大的特點就是瞬時并發流量高，在電商系統中，庫存數量往往會遠遠小于并發流量，比如：天貓的秒殺活動，可能庫存只有幾百、幾千件，而瞬間涌入的搶購并發流量可能會達到幾十到幾百萬，

所以，我們可以將秒殺系統的業務特點總結如下，

需要更多Java知識點和面試題的朋友可以點一點下方鏈接免費領取

鏈接：1103806531暗號：CSDN

（1）限時、限量、限價

在規定的時間內進行；秒殺活動中商品的數量有限；商品的價格會遠遠低于原來的價格，也就是說，在秒殺活動中，商品會以遠遠低于原來的價格出售，

例如，秒殺活動的時間僅限于某天上午10點到10點半，商品數量只有10萬件，售完為止，而且商品的價格非常低，例如：1元購等業務場景，

限時、限量和限價可以單獨存在，也可以組合存在，

（2）活動預熱

需要提前配置活動；活動還未開始時，用戶可以查看活動的相關資訊；秒殺活動開始前，對活動進行大力宣傳，

（3）持續時間短

購買的人數數量龐大；商品會迅速售完，

在系統流量呈現上，就會出現一個突刺現象，此時的并發訪問量是非常高的，大部分秒殺場景下，商品會在極短的時間內售完，

秒殺三階段

通常，從秒殺開始到結束，往往會經歷三個階段：

• 準備階段：這個階段也叫作系統預熱階段，此時會提前預熱秒殺系統的業務資料，往往這個時候，用戶會不斷重繪秒殺頁面，來查看秒殺活動是否已經開始，在一定程度上，通過用戶不斷重繪頁面的操作，可以將一些資料存盤到Redis中進行預熱，
• 秒殺階段：這個階段主要是秒殺活動的程序，會產生瞬時的高并發流量，對系統資源會造成巨大的沖擊，所以，在秒殺階段一定要做好系統防護，
• 結算階段： 完成秒殺后的資料處理作業，比如資料的一致性問題處理，例外情況處理，商品的回倉處理等，

Redis助力秒殺系統

我們可以在Redis中設計一個Hash資料結構，來支持商品庫存的扣減操作，如下所示，

seckill:goodsStock:${goodsId}{
    totalCount:200,
    initStatus:0,
    seckillCount:0
}

在我們設計的Hash資料結構中，有三個非常主要的屬性，

• totalCount：表示參與秒殺的商品的總數量，在秒殺活動開始前，我們就需要提前將此值加載到Redis快取中，
• initStatus：我們把這個值設計成一個布林值，秒殺開始前，這個值為0，表示秒殺未開始，可以通過定時任務或者后臺操作，將此值修改為1，則表示秒殺開始，
• seckillCount：表示秒殺的商品數量，在秒殺程序中，此值的上限為totalCount，當此值達到totalCount時，表示商品已經秒殺完畢，

我們可以通過下面的代碼片段在秒殺預熱階段，將要參與秒殺的商品資料加載的快取，

/**
 * @author binghe
 * @description 秒殺前構建商品快取代碼示例
 */
public class SeckillCacheBuilder{
    private static final String GOODS_CACHE = "seckill:goodsStock:"; 
    private String getCacheKey(String id) { 
        return  GOODS_CACHE.concat(id);
    } 
    public void prepare(String id, int totalCount) { 
        String key = getCacheKey(id); 
        Map<String, Integer> goods = new HashMap<>(); 
        goods.put("totalCount", totalCount); 
        goods.put("initStatus", 0); 
        goods.put("seckillCount", 0); 
        redisTemplate.opsForHash().putAll(key, goods); 
     }
}

秒殺開始的時候，我們需要在代碼中首先判斷快取中的seckillCount值是否小于totalCount值，如果seckillCount值確實小于totalCount值，我們才能夠對庫存進行鎖定，在我們的程式中，這兩步其實并不是原子性的，如果在分布式環境中，我們通過多臺機器同時操作Redis快取，就會發生同步問題，進而引起“超賣”的嚴重后果，

在電商領域，有一個專業名詞叫作“超賣”，顧名思義：“超賣”就是說賣出的商品數量比商品的庫存數量多，這在電商領域是一個非常嚴重的問題，那么，我們如何解決“超賣”問題呢？

Lua腳本完美解決超賣問題

我們如何解決多臺機器同時操作Redis出現的同步問題呢？一個比較好的方案就是使用Lua腳本，我們可以使用Lua腳本將Redis中扣減庫存的操作封裝成一個原子操作，這樣就能夠保證操作的原子性，從而解決高并發環境下的同步問題，

例如，我們可以撰寫如下的Lua腳本代碼，來執行Redis中的庫存扣減操作，

local resultFlag = "0" 
local n = tonumber(ARGV[1]) 
local key = KEYS[1] 
local goodsInfo = redis.call("HMGET",key,"totalCount","seckillCount") 
local total = tonumber(goodsInfo[1]) 
local alloc = tonumber(goodsInfo[2]) 
if not total then 
    return resultFlag 
end 
if total >= alloc + n  then 
    local ret = redis.call("HINCRBY",key,"seckillCount",n) 
    return tostring(ret) 
end 
return resultFlag

我們可以使用如下的Java代碼來呼叫上述Lua腳本，

public int secKill(String id, int number) { 
    String key = getCacheKey(id); 
    Object seckillCount =  redisTemplate.execute(script, Arrays.asList(key), String.valueOf(number)); 
    return Integer.valueOf(seckillCount.toString()); 
}

這樣，我們在執行秒殺活動時，就能夠保證操作的原子性，從而有效的避免資料的同步問題，進而有效的解決了“超賣”問題，

總結

為大家整理了各個知識點模塊整理檔案和更多大廠面試真題，有需要的朋友可以點一點下方鏈接免費領取

鏈接：1103806531暗號：CSDN