【高併發】Redis如何助力高併發秒殺系統，看完這篇我完全懂了！！

寫在前面

以前，咱們在《【高併發】高併發秒殺系統架構解密，不是全部的秒殺都是秒殺！》一文中，詳細講解了高併發秒殺系統的架構設計，其中，咱們介紹了可使用Redis存儲秒殺商品的庫存數量。不少小夥伴看完後，以爲一頭霧水，看完是看完了，那如何實現呢？今天，咱們就一塊兒來看看Redis是如何助力高併發秒殺系統的！java

有關高併發秒殺系統的架構設計，小夥伴們能夠關注 冰河技術 公衆號，查看《【高併發】高併發秒殺系統架構解密，不是全部的秒殺都是秒殺！》一文。面試

秒殺業務

在電商領域，存在着典型的秒殺業務場景，那何謂秒殺場景呢。簡單的來講就是一件商品的購買人數遠遠大於這件商品的庫存，並且這件商品在很短的時間內就會被搶購一空。好比每一年的61八、雙11大促，小米新品促銷等業務場景，就是典型的秒殺業務場景。redis

秒殺業務最大的特色就是瞬時併發流量高，在電商系統中，庫存數量每每會遠遠小於併發流量，好比：天貓的秒殺活動，可能庫存只有幾百、幾千件，而瞬間涌入的搶購併發流量可能會達到幾十到幾百萬。設計模式

因此，咱們能夠將秒殺系統的業務特色總結以下。緩存

（1）限時、限量、限價bash

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

例如，秒殺活動的時間僅限於某天上午10點到10點半，商品數量只有10萬件，售完爲止，並且商品的價格很是低，例如：1元購等業務場景。markdown

限時、限量和限價能夠單獨存在，也能夠組合存在。數據結構

（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()); 
}
複製代碼

這樣，咱們在執行秒殺活動時，就可以保證操做的原子性，從而有效的避免數據的同步問題，進而有效的解決了「超賣」問題。

重磅福利

關注「 冰河技術 」微信公衆號，後臺回覆「設計模式」關鍵字領取《深刻淺出Java 23種設計模式》PDF文檔。回覆「Java8」關鍵字領取《Java8新特性教程》PDF文檔。回覆「限流」關鍵字獲取《億級流量下的分佈式限流解決方案》PDF文檔，三本PDF均是由冰河原創並整理的超硬核教程，面試必備！！

好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一塊兒學習，一塊兒進步！！

寫在最後

若是你以爲冰河寫的還不錯，請微信搜索並關注「 冰河技術 」微信公衆號，跟冰河學習高併發、分佈式、微服務、大數據、互聯網和雲原生技術，「 冰河技術 」微信公衆號更新了大量技術專題，每一篇技術文章乾貨滿滿！很多讀者已經經過閱讀「 冰河技術 」微信公衆號文章，吊打面試官，成功跳槽到大廠；也有很多讀者實現了技術上的飛躍，成爲公司的技術骨幹！若是你也想像他們同樣提高本身的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公衆號吧，天天更新超硬核技術乾貨，讓你對如何提高技術能力再也不迷茫！