數(shù)據(jù)庫扣減

我們先來看下通過數(shù)據(jù)庫方式去實現(xiàn)。

因為要防止它超賣，所以要先把庫存鎖住，避免庫存還剩最后一個時，多個線程同時去扣減成負數(shù)了。

圖片

但是這種方式顯而易見效率非常低下，因為這里加的悲觀鎖，讀請求也被阻塞了，我們知道大部分場景下都是讀多寫少，所以如何優(yōu)化呢？

很快小白想到了，可以通過樂觀鎖的方式實現(xiàn)。

樂觀鎖：事務(wù)不會在讀取數(shù)據(jù)時加鎖，而是繼續(xù)執(zhí)行后續(xù)操作，只有在提交數(shù)據(jù)時才會檢查數(shù)據(jù)是否已經(jīng)被其他事務(wù)修改，通常通過 版本號或時間戳來實現(xiàn)。

我們可以給庫存這條記錄加一個版本號字段 version，在更新庫存時判斷版本號是否一致，這樣也不會阻塞讀請求。

UPDATE product_inventory
SET stock = stock - :quantity,
    version = version + 1
WHERE product_id = :productId
  AND version = :version;

這種方式能滿足一般場景，但是假設(shè)在高并發(fā)的搶購活動下，當(dāng)你壓測時發(fā)現(xiàn) TPS 怎么也提不上來。

高并發(fā)場景下使用樂觀鎖，一是其他請求拿不到版本號導(dǎo)致線程一直自旋等待中，甚至?xí)档拖到y(tǒng)的性能。二是數(shù)據(jù)庫的性能瓶頸。

這時，你在想有沒有其他更好的方式呢？

Redis 扣減

既然數(shù)據(jù)庫無法滿足高并發(fā)性能，我們知道 Redis 單節(jié)點理論能支持幾萬級 TPS，而且我們還可以部署集群多節(jié)點，這樣肯定能滿足了吧。

Redis 如何實現(xiàn)庫存扣減呢？

很快，你想到了，Redis 不是有一個 INCRBY 的命令嗎？可以通過這個實現(xiàn)呀。

INCRBY product:1001:stock -10

但很快，測試時你又發(fā)現(xiàn)了問題，在場景下，這個庫存會被扣成負數(shù)，這顯然是不能接受的。

那再加上鎖不就好了嗎，因為是是節(jié)點操作，我們想到通過加分布式鎖的方式。

圖片

同一時刻只有一個線程能獲取到鎖去執(zhí)行扣減，這樣肯定不會超賣了，但這種方式因為只有一個線程能去扣減這個商品的庫存，顯然并發(fā)性能還有待提升。

我們可以不加鎖嗎？但判斷庫存是否大于 0 和扣減庫存是兩個指令，如何保證一致性呢？

Redis Lua 扣減

Lua：Redis 支持在服務(wù)器端執(zhí)行 Lua 腳本時，腳本的所有操作都是原子執(zhí)行的，即腳本中的所有命令要么全部成功，要么全部失敗。

我們可以通過 Lua 的原子性來實現(xiàn)，避免加鎖。

先獲取當(dāng)前庫存，判斷是否足夠，如果足夠再進行扣減。

local stock = redis.call('get', KEYS[1])  -- 獲取當(dāng)前庫存
if not stock then
    return nil  -- 如果沒有找到庫存，返回nil
end

if tonumber(stock) >= tonumber(ARGV[1]) then  -- 如果庫存足夠
    redis.call('decrby', KEYS[1], ARGV[1])  -- 扣減庫存
    return tonumber(stock) - tonumber(ARGV[1])  -- 返回扣減后的庫存
else
    return nil  -- 庫存不足，返回nil
end

如果這時老板看商品賣的很好，要后臺調(diào)增庫存怎么辦？

如果要調(diào)增庫存，為了防止多個線程同時調(diào)整庫存出現(xiàn)并發(fā)問題，這里要加分布式鎖，可以通過 SETNX 實現(xiàn)。

/**
     * 增加庫存，使用分布式鎖確保并發(fā)安全
     * @param productId 商品ID
     * @param quantity 增加的數(shù)量
     * @param lockValue 鎖的值，用于解鎖時進行驗證
     * @param lockTimeout 鎖的超時時間
     * @return 是否成功增加庫存
     */
    public boolean increaseInventoryWithLock(String productId, int quantity, String lockValue, int lockTimeout) {
        try (Jedis jedis = jedisPool.getResource()) {
            // 獲取分布式鎖
            String lockKey = "product_lock:" + productId;
            boolean lockAcquired = acquireLock(jedis, lockKey, lockValue, lockTimeout);
            if (lockAcquired) {
                try {
                    // 增加庫存
                    jedis.incrBy("product:" + productId + ":stock", quantity);
                    return true;
                } finally {
                    // 釋放鎖
                    releaseLock(jedis, lockKey, lockValue);
                }
            } else {
                // 如果獲取不到鎖，可以返回 false 或進行重試等操作
                return false;
            }
        }
    }

這樣，你想應(yīng)該就萬無一失了吧。

但是，如果你的商品賣得非常好，Redis 單節(jié)點也扛不住了，針對這種熱點商品怎么辦呢？

Redis 庫存分片

莫慌，別忘了我們 Redis 是多節(jié)點集群部署的，我們?nèi)绻堰@個熱點商品庫存拆分到每個節(jié)點上不就解決了嗎。

怎么拆分呢？

假設(shè)我們 Redis 有 12 個節(jié)點，我們可以把商品庫存緩存 Key 再加個后綴 0，1，2....12 分布到每一個節(jié)點上，扣減時如果發(fā)現(xiàn)當(dāng)前節(jié)點沒庫存了，再扣除下個緩存 key。

當(dāng)然，如果每次都從節(jié)點 1 開始，熱點問題并沒有解決，我們可以設(shè)置一個隨機數(shù)組把順序打散，比如[1，2，......，12]，[2,12......,1]。

圖片

這樣避免了該熱點商品的所有請求都打到同一個節(jié)點上的問題了。