一、全局唯一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ù)進(jìn)行了修改。如果沒有修改則認(rèn)為是安全的，自己才更新數(shù)據(jù)；如果已經(jīng)被其他線程修改，說明了安全問題，此時可以重試或異常。

2、樂觀鎖

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

（1）版本號法

（2）CAS法

（3）總結(jié)

四、分布式鎖

傳送門

五、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。

2、PubSub

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

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

3、Stream

（1）基本用法

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

特點：

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

（2）消費者組

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

確認(rèn)pending-list

查看pendingList

特點：

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

4、比較

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

最新評論