Redis秒殺實現方案講解

一、全域性唯一ID

（1）定義

全域性ID生成器，是一種在分散式系統下用來生成全域性唯一ID的工具，一半滿足下列特性：

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

為了增加ID的安全性，我們不直接使用Redis自增的數值，而是拼接一些其他的資訊。

ID的組成部分：

• 符號位：1bit，永遠為0
• 時間戳：31bit，以秒為單位，可以使用69年
• 序列號：32bit，秒內計數器，支援每秒產生2ⁿ32個不同的ID

（2）程式碼實現

@Component
public class RedisIdWorker {
    /**
     * 開始時間戳
     */
    private static final long BEGIN_TIMESTAMP = 1640995200L;
    /**
     * 序列號的位數
     */
    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.獲取當前日期，精確到天
        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）總結

全域性唯一ID生成策略：

• UUID
• Redis自增
• 雪花演演算法
• 資料庫自增

Redis自增ID策略：

• 每天一個key，方便統計
• ID構造是時間戳 + 計數器

二、超賣問題

1、解決辦法

超賣問題是典型的多執行緒安全問題，針對這一問題的常見解決方案就是加鎖：

悲觀鎖

認為執行緒安全問題一定會發生，因此在運算元據之前先獲取鎖，確保執行緒序列執行。例如Synchronized、Lock都屬於悲觀鎖

樂觀鎖

認為執行緒安全問題不一定會發生，因此不加鎖，只是在更新資料時去判斷有沒有其他執行緒對資料進行了修改。如果沒有修改則認為是安全的，自己才更新資料；如果已經被其他執行緒修改，說明了安全問題，此時可以重試或異常。

2、樂觀鎖

樂觀鎖的關鍵是判斷之前查詢得到的資料是否有被修改過，常見的方式有兩種：

（1）版本號法

（2）CAS法

（3）總結

四、分散式鎖

傳送門

五、Reids優化秒殺—非同步執行

1、思路

（1）Lua指令碼邏輯

判斷庫存是否充足：利用String型別

判斷使用者是否下單：利用Set型別

（2）java執行Lua指令碼邏輯

（3）程式碼

-- 1.參數列
-- 1.1.優惠券id
local voucherId = ARGV[1]
-- 1.2.使用者id
local userId = ARGV[2]

-- 2.資料key
-- 2.1.庫存key
local stockKey = 'seckill:stock:' .. voucherId
-- 2.2.訂單key
local orderKey = 'seckill:order:' .. voucherId

-- 3.指令碼業務
-- 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.存在，說明是重複下單，返回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.執行lua指令碼
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(),
                voucherId.toString(), userId.toString()
        );
        int r = result.intValue();
        // 2.判斷結果是否為0
        if (r != 0) {
            // 2.1.不為0 ，代表沒有購買資格
            return Result.fail(r == 1 ? "庫存不足" : "不能重複下單");
        }
        // 3.傳送訊息佇列 非同步
        // 4.返回訂單id
        return Result.ok(orderId);
    }

六、訊息佇列

訊息佇列（Message Queue）,字面意思就是存放訊息的佇列。最簡單的訊息佇列模型包括3個角色：

• 訊息佇列：儲存和管理訊息，也被成為訊息代理。
• 生產者：傳送訊息導訊息佇列
• 消費者：從訊息佇列獲取訊息並處理訊息。

Redis提供了三種不同的方式來實現訊息佇列：

• list結構：基於Liist結構模擬訊息佇列
• PubSub：基本的對等訊息模型
• Stream：比較完善的訊息佇列模型

1、基於List結構模擬訊息佇列

訊息佇列就是存放訊息的佇列。而Redis的List資料結構是一個雙向連結串列，很容易模擬。

佇列是入口和出口不在一邊，因此可以利用LPUSH結合RPOP來實現。

實現阻塞效果，應該使用BRPOP。

2、PubSub

釋出訂閱模式，消費者可以訂閱一個或多個channel，生產者向對應channel傳送訊息後，所有訂閱者都能收到相關訊息。

• SUBSCRIBE channel [channel] ：訂閱一個或多個頻道
• PUBLISH channel msg: 向一個頻道傳送訊息
• PSUBSCRIBE pattern [pattern] :訂閱與pattern格式匹配的所有頻道

3、Stream

（1）基本用法

是Redis 5.0引入的新資料

特點：

• 訊息可回溯一個訊息可以被多個消費者讀取
• 可以阻塞讀取
• 有訊息漏讀的風險

（2）消費者組

消費者組（Consumer Group）：將多個消費者劃分到一個組中，監聽同一個佇列。特點如下：

確認pending-list

檢視pendingList

特點：

• 訊息可回溯
• 可以多消費者爭搶訊息，加快消費速度
• 可以阻塞讀取
• 沒有訊息漏讀的風險
• 有訊息確認機制，保證訊息至少被消費一次

4、比較

到此這篇關於Redis秒殺實現方案講解的文章就介紹到這了,更多相關Redis秒殺內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！