一、全局唯一ID

（1）定義

全局ID生成器，是一種在分布式系統(tǒng)下用來(lái)生成全局唯一ID的工具，一半滿足下列特性：

• 唯一性
• 高可用
• 高性能
• 遞增性
• 安全性

為了增加ID的安全性，我們不直接使用Redis自增的數(shù)值，而是拼接一些其他的信息。

ID的組成部分：

• 符號(hào)位：1bit，永遠(yuǎn)為0
• 時(shí)間戳：31bit，以秒為單位，可以使用69年
• 序列號(hào)：32bit，秒內(nèi)計(jì)數(shù)器，支持每秒產(chǎn)生2?32個(gè)不同的ID

（2）代碼實(shí)現(xiàn)

@Component
public class RedisIdWorker {
    /**
     * 開始時(shí)間戳
     */
    private static final long BEGIN_TIMESTAMP = 1640995200L;
    /**
     * 序列號(hào)的位數(shù)
     */
    private static final int COUNT_BITS = 32;
    @Autowired
    private StringRedisTemplate stringRedisTemplate;
    public long nextId(String keyPrefix) {
        // 1.生成時(shí)間戳
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp = nowSecond - BEGIN_TIMESTAMP;
        // 2.生成序列號(hào)
        // 2.1.獲取當(dāng)前日期，精確到天
        String date = now.format(DateTimeFormatter
        						.ofPattern("yyyy:MM:dd"));
        // 2.2.自增長(zhǎng)
        long count = stringRedisTemplate.opsForValue()
        					.increment("icr:" + keyPrefix + ":" + date);
        // 3.拼接并返回
        return timestamp << COUNT_BITS | count;
    }
}

（3）總結(jié)

全局唯一ID生成策略：

• UUID
• Redis自增
• 雪花算法
• 數(shù)據(jù)庫(kù)自增

Redis自增ID策略：

• 每天一個(gè)key，方便統(tǒng)計(jì)
• ID構(gòu)造是時(shí)間戳 + 計(jì)數(shù)器

二、超賣問(wèn)題

1、解決辦法

超賣問(wèn)題是典型的多線程安全問(wèn)題，針對(duì)這一問(wèn)題的常見(jiàn)解決方案就是加鎖：

悲觀鎖

認(rèn)為線程安全問(wèn)題一定會(huì)發(fā)生，因此在操作數(shù)據(jù)之前先獲取鎖，確保線程串行執(zhí)行。例如Synchronized、Lock都屬于悲觀鎖

樂(lè)觀鎖

認(rèn)為線程安全問(wèn)題不一定會(huì)發(fā)生，因此不加鎖，只是在更新數(shù)據(jù)時(shí)去判斷有沒(méi)有其他線程對(duì)數(shù)據(jù)進(jìn)行了修改。如果沒(méi)有修改則認(rèn)為是安全的，自己才更新數(shù)據(jù)；如果已經(jīng)被其他線程修改，說(shuō)明了安全問(wèn)題，此時(shí)可以重試或異常。

2、樂(lè)觀鎖

樂(lè)觀鎖的關(guān)鍵是判斷之前查詢得到的數(shù)據(jù)是否有被修改過(guò)，常見(jiàn)的方式有兩種：

（1）版本號(hào)法

（2）CAS法

（3）總結(jié)

四、分布式鎖

傳送門

五、Reids優(yōu)化秒殺—異步執(zhí)行

1、思路

（1）Lua腳本邏輯

判斷庫(kù)存是否充足：利用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.庫(kù)存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.訂單key
local orderKey = 'seckill:order:' .. voucherId

-- 3.腳本業(yè)務(wù)
-- 3.1.判斷庫(kù)存是否充足 get stockKey
if(tonumber(redis.call('get', stockKey)) <= 0) then
    -- 3.2.庫(kù)存不足，返回1
    return 1
end
-- 3.2.判斷用戶是否下單 SISMEMBER orderKey userId
if(redis.call('sismember', orderKey, userId) == 1) then
    -- 3.3.存在，說(shuō)明是重復(fù)下單，返回2
    return 2
end
-- 3.4.扣庫(kù)存 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 ，代表沒(méi)有購(gòu)買資格
            return Result.fail(r == 1 ? "庫(kù)存不足" : "不能重復(fù)下單");
        }
        // 3.發(fā)送消息隊(duì)列 異步
        // 4.返回訂單id
        return Result.ok(orderId);
    }

六、消息隊(duì)列

消息隊(duì)列（Message Queue）,字面意思就是存放消息的隊(duì)列。最簡(jiǎn)單的消息隊(duì)列模型包括3個(gè)角色：

• 消息隊(duì)列：存儲(chǔ)和管理消息，也被成為消息代理。
• 生產(chǎn)者：發(fā)送消息導(dǎo)消息隊(duì)列
• 消費(fèi)者：從消息隊(duì)列獲取消息并處理消息。

Redis提供了三種不同的方式來(lái)實(shí)現(xiàn)消息隊(duì)列：

• list結(jié)構(gòu)：基于Liist結(jié)構(gòu)模擬消息隊(duì)列
• PubSub：基本的點(diǎn)對(duì)點(diǎn)消息模型
• Stream：比較完善的消息隊(duì)列模型

1、基于List結(jié)構(gòu)模擬消息隊(duì)列

消息隊(duì)列就是存放消息的隊(duì)列。而Redis的List數(shù)據(jù)結(jié)構(gòu)是一個(gè)雙向鏈表，很容易模擬。

隊(duì)列是入口和出口不在一邊，因此可以利用LPUSH結(jié)合RPOP來(lái)實(shí)現(xiàn)。

實(shí)現(xiàn)阻塞效果，應(yīng)該使用BRPOP。

2、PubSub

發(fā)布訂閱模式，消費(fèi)者可以訂閱一個(gè)或多個(gè)channel，生產(chǎn)者向?qū)?yīng)channel發(fā)送消息后，所有訂閱者都能收到相關(guān)消息。

• SUBSCRIBE channel [channel] ：訂閱一個(gè)或多個(gè)頻道
• PUBLISH channel msg: 向一個(gè)頻道發(fā)送消息
• PSUBSCRIBE pattern [pattern] :訂閱與pattern格式匹配的所有頻道

3、Stream

（1）基本用法

是Redis 5.0引入的新數(shù)據(jù)

特點(diǎn)：

• 消息可回溯一個(gè)消息可以被多個(gè)消費(fèi)者讀取
• 可以阻塞讀取
• 有消息漏讀的風(fēng)險(xiǎn)

（2）消費(fèi)者組

消費(fèi)者組（Consumer Group）：將多個(gè)消費(fèi)者劃分到一個(gè)組中，監(jiān)聽同一個(gè)隊(duì)列。特點(diǎn)如下：

確認(rèn)pending-list

查看pendingList

特點(diǎn)：

• 消息可回溯
• 可以多消費(fèi)者爭(zhēng)搶消息，加快消費(fèi)速度
• 可以阻塞讀取
• 沒(méi)有消息漏讀的風(fēng)險(xiǎn)
• 有消息確認(rèn)機(jī)制，保證消息至少被消費(fèi)一次

4、比較

到此這篇關(guān)于Redis秒殺實(shí)現(xiàn)方案講解的文章就介紹到這了,更多相關(guān)Redis秒殺內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論