寫在前面
之前，我們在《【高並發】高並發秒殺系統架構解密，不是所有的秒殺都是秒殺！》一文中，詳細講解了高並發秒殺系統的架構設計，其中，我們介紹了可以使用Redis存儲秒殺商品的庫存數量。很多小伙伴看完后，覺得一頭霧水，看完是看完了，那如何實現呢？今天，我們就一起來看看Redis是如何助力高並發秒殺系統的！
有關高並發秒殺系統的架構設計，小伙伴們可以關注 冰河技術 公眾號，查看《【高並發】高並發秒殺系統架構解密，不是所有的秒殺都是秒殺！》一文。
秒殺業務
在電商領域，存在着典型的秒殺業務場景，那何謂秒殺場景呢。簡單的來說就是一件商品的購買人數遠遠大於這件商品的庫存，而且這件商品在很短的時間內就會被搶購一空。比如每年的618、雙11大促，小米新品促銷等業務場景，就是典型的秒殺業務場景。
秒殺業務最大的特點就是瞬時並發流量高，在電商系統中，庫存數量往往會遠遠小於並發流量，比如：天貓的秒殺活動，可能庫存只有幾百、幾千件，而瞬間涌入的搶購並發流量可能會達到幾十到幾百萬。
所以，我們可以將秒殺系統的業務特點總結如下。
（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());
}
這樣，我們在執行秒殺活動時，就能夠保證操作的原子性，從而有效的避免數據的同步問題，進而有效的解決了“超賣”問題。
重磅福利
關注「 冰河技術 」微信公眾號，后台回復 “設計模式” 關鍵字領取《深入淺出Java 23種設計模式》PDF文檔。回復“Java8”關鍵字領取《Java8新特性教程》PDF文檔。回復“限流”關鍵字獲取《億級流量下的分布式限流解決方案》PDF文檔，三本PDF均是由冰河原創並整理的超硬核教程，面試必備！！
好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一起學習，一起進步！！
寫在最后
如果你覺得冰河寫的還不錯，請微信搜索並關注「 冰河技術 」微信公眾號，跟冰河學習高並發、分布式、微服務、大數據、互聯網和雲原生技術，「 冰河技術 」微信公眾號更新了大量技術專題，每一篇技術文章干貨滿滿！不少讀者已經通過閱讀「 冰河技術 」微信公眾號文章，吊打面試官，成功跳槽到大廠；也有不少讀者實現了技術上的飛躍，成為公司的技術骨干！如果你也想像他們一樣提升自己的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公眾號吧，每天更新超硬核技術干貨，讓你對如何提升技術能力不再迷茫！
