Redis秒殺實現(xiàn)方案講解
一、全局唯一ID
(1)定義
全局ID生成器,是一種在分布式系統(tǒng)下用來生成全局唯一ID的工具,一半滿足下列特性:
- 唯一性
- 高可用
- 高性能
- 遞增性
- 安全性
為了增加ID的安全性,我們不直接使用Redis自增的數(shù)值,而是拼接一些其他的信息。
ID的組成部分:
- 符號位:1bit,永遠(yuǎn)為0
- 時間戳:31bit,以秒為單位,可以使用69年
- 序列號:32bit,秒內(nèi)計數(shù)器,支持每秒產(chǎn)生2?32個不同的ID
(2)代碼實現(xiàn)
@Component public class RedisIdWorker { /** * 開始時間戳 */ private static final long BEGIN_TIMESTAMP = 1640995200L; /** * 序列號的位數(shù) */ private static final int COUNT_BITS = 32; @Autowired private StringRedisTemplate stringRedisTemplate; public long nextId(String keyPrefix) { // 1.生成時間戳 LocalDateTime now = LocalDateTime.now(); long nowSecond = now.toEpochSecond(ZoneOffset.UTC); long timestamp = nowSecond - BEGIN_TIMESTAMP; // 2.生成序列號 // 2.1.獲取當(dāng)前日期,精確到天 String date = now.format(DateTimeFormatter .ofPattern("yyyy:MM:dd")); // 2.2.自增長 long count = stringRedisTemplate.opsForValue() .increment("icr:" + keyPrefix + ":" + date); // 3.拼接并返回 return timestamp << COUNT_BITS | count; } }
(3)總結(jié)
全局唯一ID生成策略:
- UUID
- Redis自增
- 雪花算法
- 數(shù)據(jù)庫自增
Redis自增ID策略:
- 每天一個key,方便統(tǒng)計
- ID構(gòu)造是時間戳 + 計數(shù)器
二、超賣問題
1、解決辦法
超賣問題是典型的多線程安全問題,針對這一問題的常見解決方案就是加鎖:
悲觀鎖
認(rèn)為線程安全問題一定會發(fā)生,因此在操作數(shù)據(jù)之前先獲取鎖,確保線程串行執(zhí)行。例如Synchronized、Lock都屬于悲觀鎖
樂觀鎖
認(rèn)為線程安全問題不一定會發(fā)生,因此不加鎖,只是在更新數(shù)據(jù)時去判斷有沒有其他線程對數(shù)據(jù)進行了修改。如果沒有修改則認(rèn)為是安全的,自己才更新數(shù)據(jù);如果已經(jīng)被其他線程修改,說明了安全問題,此時可以重試或異常。
2、樂觀鎖
樂觀鎖的關(guān)鍵是判斷之前查詢得到的數(shù)據(jù)是否有被修改過,常見的方式有兩種:
(1)版本號法
(2)CAS法
(3)總結(jié)
悲觀鎖 | 樂觀鎖 | |
---|---|---|
方案 | 添加同步鎖,讓線程串行執(zhí)行 | 不加鎖,在更新時判斷是否有其他線程在修改 |
優(yōu)點 | 簡單粗暴 | 性能好 |
缺點 | 性能一般 | 存在成功率低的問題 |
四、分布式鎖
五、Reids優(yōu)化秒殺—異步執(zhí)行
1、思路
(1)Lua腳本邏輯
判斷庫存是否充足:利用String類型
判斷用戶是否下單:利用Set類型
(2)java執(zhí)行Lua腳本邏輯
(3)代碼
-- 1.參數(shù)列表
-- 1.1.優(yōu)惠券id
local voucherId = ARGV[1]
-- 1.2.用戶id
local userId = ARGV[2]-- 2.數(shù)據(jù)key
-- 2.1.庫存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.訂單key
local orderKey = 'seckill:order:' .. voucherId-- 3.腳本業(yè)務(wù)
-- 3.1.判斷庫存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
-- 3.2.庫存不足,返回1
return 1
end
-- 3.2.判斷用戶是否下單 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
-- 3.3.存在,說明是重復(fù)下單,返回2
return 2
end
-- 3.4.扣庫存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
-- 3.5.下單(保存用戶)sadd orderKey userId
redis.call('sadd', orderKey, userId)
return 0
private static final DefaultRedisScript<Long> SECKILL_SCRIPT; static { SECKILL_SCRIPT = new DefaultRedisScript<>(); SECKILL_SCRIPT.setLocation(new ClassPathResource("seckill.lua")); SECKILL_SCRIPT.setResultType(Long.class); } @Override public Result seckillVoucher(Long voucherId) { Long userId = UserHolder.getUser().getId(); long orderId = redisIdWorker.nextId("order"); // 1.執(zhí)行l(wèi)ua腳本 Long result = stringRedisTemplate.execute( SECKILL_SCRIPT, Collections.emptyList(), voucherId.toString(), userId.toString() ); int r = result.intValue(); // 2.判斷結(jié)果是否為0 if (r != 0) { // 2.1.不為0 ,代表沒有購買資格 return Result.fail(r == 1 ? "庫存不足" : "不能重復(fù)下單"); } // 3.發(fā)送消息隊列 異步 // 4.返回訂單id return Result.ok(orderId); }
六、消息隊列
消息隊列(Message Queue),字面意思就是存放消息的隊列。最簡單的消息隊列模型包括3個角色:
- 消息隊列:存儲和管理消息,也被成為消息代理。
- 生產(chǎn)者:發(fā)送消息導(dǎo)消息隊列
- 消費者:從消息隊列獲取消息并處理消息。
Redis提供了三種不同的方式來實現(xiàn)消息隊列:
- list結(jié)構(gòu):基于Liist結(jié)構(gòu)模擬消息隊列
- PubSub:基本的點對點消息模型
- Stream:比較完善的消息隊列模型
1、基于List結(jié)構(gòu)模擬消息隊列
消息隊列就是存放消息的隊列。而Redis的List數(shù)據(jù)結(jié)構(gòu)是一個雙向鏈表,很容易模擬。
隊列是入口和出口不在一邊,因此可以利用LPUSH結(jié)合RPOP來實現(xiàn)。
實現(xiàn)阻塞效果,應(yīng)該使用BRPOP。
描述 | |
---|---|
優(yōu)點 | 1、利用Redis存儲,不受限于JVM內(nèi)存上限; 2、基于Redis的持久化機制,數(shù)據(jù)安全性有保障 3、可以滿足消息有序性 |
缺點 | 1、無法避免消息丟失 2、只支持單消費者 |
2、PubSub
發(fā)布訂閱模式,消費者可以訂閱一個或多個channel,生產(chǎn)者向?qū)?yīng)channel發(fā)送消息后,所有訂閱者都能收到相關(guān)消息。
- SUBSCRIBE channel [channel] :訂閱一個或多個頻道
- PUBLISH channel msg: 向一個頻道發(fā)送消息
- PSUBSCRIBE pattern [pattern] :訂閱與pattern格式匹配的所有頻道
描述 | |
---|---|
優(yōu)點 | 1、采用發(fā)布訂閱模式,支持多生產(chǎn)、多消費 |
缺點 | 1、不支持?jǐn)?shù)據(jù)持久化 2、無法避免消息丟失 3、消息堆積有上限,超出時數(shù)據(jù)丟失 |
3、Stream
(1)基本用法
是Redis 5.0引入的新數(shù)據(jù)
特點:
- 消息可回溯一個消息可以被多個消費者讀取
- 可以阻塞讀取
- 有消息漏讀的風(fēng)險
(2)消費者組
消費者組(Consumer Group):將多個消費者劃分到一個組中,監(jiān)聽同一個隊列。特點如下:
確認(rèn)pending-list
查看pendingList
特點:
- 消息可回溯
- 可以多消費者爭搶消息,加快消費速度
- 可以阻塞讀取
- 沒有消息漏讀的風(fēng)險
- 有消息確認(rèn)機制,保證消息至少被消費一次
4、比較
List | PubSub | Stream | |
---|---|---|---|
消息持久化 | 支持 | 不支持 | 支持 |
阻塞讀取 | 支持 | 支持 | 支持 |
消息堆積處理 | 受限于內(nèi)存空間,可以利用多消費者加快處理 | 受限于消費者緩沖區(qū) | 受限于隊列長度,可以利用消費者組提高消息速度,減少堆積 |
消息回溯 | 不支持 | 不支持 | 支持 |
到此這篇關(guān)于Redis秒殺實現(xiàn)方案講解的文章就介紹到這了,更多相關(guān)Redis秒殺內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis五種數(shù)據(jù)結(jié)構(gòu)在JAVA中如何封裝使用
本篇博文就針對Redis的五種數(shù)據(jù)結(jié)構(gòu)以及如何在JAVA中封裝使用做一個簡單的介紹。對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2021-11-11使用Redis命令操作數(shù)據(jù)庫的常見錯誤及解決方法
由于Redis是內(nèi)存數(shù)據(jù)庫,因此可能會存在一些安全問題,下面這篇文章主要給大家介紹了關(guān)于使用Redis命令操作數(shù)據(jù)庫的常見錯誤及解決方法,文中通過代碼介紹的非常詳細(xì),需要的朋友可以參考下2024-02-02