秒殺業(yè)務
在電商領域,存在著典型的秒殺業(yè)務場景,那何謂秒殺場景呢。簡單的來說就是一件商品的購買人數(shù)遠遠大于這件商品的庫存,而且這件商品在很短的時間內就會被搶購一空。比如每年的618、雙11大促,小米新品促銷等業(yè)務場景,就是典型的秒殺業(yè)務場景。
秒殺業(yè)務最大的特點就是瞬時并發(fā)流量高,在電商系統(tǒng)中,庫存數(shù)量往往會遠遠小于并發(fā)流量,比如:天貓的秒殺活動,可能庫存只有幾百、幾千件,而瞬間涌入的搶購并發(fā)流量可能會達到幾十到幾百萬。
所以,我們可以將秒殺系統(tǒng)的業(yè)務特點總結如下。
(1)限時、限量、限價
在規(guī)定的時間內進行;秒殺活動中商品的數(shù)量有限;商品的價格會遠遠低于原來的價格,也就是說,在秒殺活動中,商品會以遠遠低于原來的價格出售。
例如,秒殺活動的時間僅限于某天上午10點到10點半,商品數(shù)量只有10萬件,售完為止,而且商品的價格非常低,例如:1元購等業(yè)務場景。
限時、限量和限價可以單獨存在,也可以組合存在。
(2)活動預熱
需要提前配置活動;活動還未開始時,用戶可以查看活動的相關信息;秒殺活動開始前,對活動進行大力宣傳。
(3)持續(xù)時間短
購買的人數(shù)數(shù)量龐大;商品會迅速售完。
在系統(tǒng)流量呈現(xiàn)上,就會出現(xiàn)一個突刺現(xiàn)象,此時的并發(fā)訪問量是非常高的,大部分秒殺場景下,商品會在極短的時間內售完。
秒殺三階段
通常,從秒殺開始到結束,往往會經歷三個階段:
-
準備階段:這個階段也叫作系統(tǒng)預熱階段,此時會提前預熱秒殺系統(tǒng)的業(yè)務數(shù)據(jù),往往這個時候,用戶會不斷刷新秒殺頁面,來查看秒殺活動是否已經開始。在一定程度上,通過用戶不斷刷新頁面的操作,可以將一些數(shù)據(jù)存儲到Redis中進行預熱。
-
秒殺階段:這個階段主要是秒殺活動的過程,會產生瞬時的高并發(fā)流量,對系統(tǒng)資源會造成巨大的沖擊,所以,在秒殺階段一定要做好系統(tǒng)防護。
- 結算階段: 完成秒殺后的數(shù)據(jù)處理工作,比如數(shù)據(jù)的一致性問題處理,異常情況處理,商品的回倉處理等。
Redis助力秒殺系統(tǒng)
我們可以在Redis中設計一個Hash數(shù)據(jù)結構,來支持商品庫存的扣減操作,如下所示。
seckill:goodsStock:${goodsId}{
?totalCount:200,
?initStatus:0,
?seckillCount:0
}
在我們設計的Hash數(shù)據(jù)結構中,有三個非常主要的屬性。
- totalCount:表示參與秒殺的商品的總數(shù)量,在秒殺活動開始前,我們就需要提前將此值加載到Redis緩存中。
- initStatus:我們把這個值設計成一個布爾值。秒殺開始前,這個值為0,表示秒殺未開始??梢酝ㄟ^定時任務或者后臺操作,將此值修改為1,則表示秒殺開始。
- seckillCount:表示秒殺的商品數(shù)量,在秒殺過程中,此值的上限為totalCount,當此值達到totalCount時,表示商品已經秒殺完畢。
我們可以通過下面的代碼片段在秒殺預熱階段,將要參與秒殺的商品數(shù)據(jù)加載的緩存。
/** ?* @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?goods?= new HashMap<>();? ????????goods.put("totalCount",?totalCount);? ????????goods.put("initStatus", 0);? ????????goods.put("seckillCount", 0);? ????????redisTemplate.opsForHash().putAll(key,?goods);? ?????} }
秒殺開始的時候,我們需要在代碼中首先判斷緩存中的seckillCount值是否小于totalCount值,如果seckillCount值確實小于totalCount值,我們才能夠對庫存進行鎖定。在我們的程序中,這兩步其實并不是原子性的。如果在分布式環(huán)境中,我們通過多臺機器同時操作Redis緩存,就會發(fā)生同步問題,進而引起“超賣”的嚴重后果。
在電商領域,有一個專業(yè)名詞叫作“超賣”。顧名思義:“超賣”就是說賣出的商品數(shù)量比商品的庫存數(shù)量多,這在電商領域是一個非常嚴重的問題。那么,我們如何解決“超賣”問題呢?
Lua腳本完美解決超賣問題
我們如何解決多臺機器同時操作Redis出現(xiàn)的同步問題呢?一個比較好的方案就是使用Lua腳本。我們可以使用Lua腳本將Redis中扣減庫存的操作封裝成一個原子操作,這樣就能夠保證操作的原子性,從而解決高并發(fā)環(huán)境下的同步問題。
例如,我們可以編寫如下的Lua腳本代碼,來執(zhí)行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());? }
這樣,我們在執(zhí)行秒殺活動時,就能夠保證操作的原子性,從而有效的避免數(shù)據(jù)的同步問題,進而有效的解決了“超賣”問題。
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!