一、全局唯一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、比較