大家好！我是sum墨，一個(gè)一線的底層碼農(nóng)，平時(shí)喜歡研究和思考一些技術(shù)相關(guān)的問(wèn)題并整理成文，限于本人水平，如果文章和代碼有表述不當(dāng)之處，還請(qǐng)不吝賜教。

以下是正文！

先看問(wèn)題

首先上一串代碼

public String buy(Long goodsId, Integer goodsNum) {
    //查詢商品庫(kù)存
    Goods goods = goodsMapper.selectById(goodsId);
    //如果當(dāng)前庫(kù)存為0，提示商品已經(jīng)賣光了
    if (goods.getGoodsInventory() <= 0) {
        return "商品已經(jīng)賣光了！";
    }
    //如果當(dāng)前購(gòu)買數(shù)量大于庫(kù)存，提示庫(kù)存不足
    if (goodsNum > goods.getGoodsInventory()) {
        return "庫(kù)存不足！";
    }
    //更新庫(kù)存
    goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
    goodsMapper.updateById(goods);
    return "購(gòu)買成功！";
}

我們看一下這串代碼，邏輯用流程圖表示如下：

從圖上看，邏輯還是很清晰明了的，而且單測(cè)的話，也測(cè)試不出來(lái)什么bug。但是在秒殺場(chǎng)景下，問(wèn)題可就大發(fā)了，100件商品可能賣出1000單，出現(xiàn)超賣問(wèn)題，這下就真的需要?dú)€(gè)程序員祭天了。

問(wèn)題分析

正常情況下，如果請(qǐng)求是一個(gè)一個(gè)接著來(lái)的話，這串代碼也不會(huì)有問(wèn)題，如下圖：

不同的時(shí)刻不同的請(qǐng)求，每次拿到的商品庫(kù)存都是更新過(guò)之后的，邏輯是ok的。

那為啥會(huì)出現(xiàn)超賣問(wèn)題呢？
首先我們給這串代碼增加一個(gè)場(chǎng)景：商品秒殺（非秒殺場(chǎng)景難以復(fù)現(xiàn)超賣問(wèn)題）。
秒殺場(chǎng)景的特點(diǎn)如下：

• 高并發(fā)處理：秒殺場(chǎng)景下，可能會(huì)有大量的購(gòu)物者同時(shí)涌入系統(tǒng)，因此需要具備高并發(fā)處理能力，保證系統(tǒng)能夠承受高并發(fā)訪問(wèn)，并提供快速的響應(yīng)。
• 快速響應(yīng)：秒殺場(chǎng)景下，由于時(shí)間限制和競(jìng)爭(zhēng)激烈，需要系統(tǒng)能夠快速響應(yīng)購(gòu)物者的請(qǐng)求，否則可能會(huì)導(dǎo)致購(gòu)買失敗，影響購(gòu)物者的購(gòu)物體驗(yàn)。
• 分布式系統(tǒng)： 秒殺場(chǎng)景下，單臺(tái)服務(wù)器扛不住請(qǐng)求高峰，分布式系統(tǒng)可以提高系統(tǒng)的容錯(cuò)能力和抗壓能力，非常適合秒殺場(chǎng)景。

在這種場(chǎng)景下，請(qǐng)求不可能是一個(gè)接一個(gè)這種，而是成千上萬(wàn)個(gè)請(qǐng)求同時(shí)打過(guò)來(lái)，那么就會(huì)出現(xiàn)多個(gè)請(qǐng)求在同一時(shí)刻查詢庫(kù)存，如下圖：

如果在同一時(shí)刻查詢商品庫(kù)存表，那么得到的商品庫(kù)存也肯定是相同的，判斷的邏輯也是相同的。

舉個(gè)例子，現(xiàn)在商品的庫(kù)存是10件，請(qǐng)求1買6件，請(qǐng)求2買5件，由于兩次請(qǐng)求查詢到的庫(kù)存都是10，肯定是可以賣的。
但是真實(shí)情況是5+6=11>10，明顯有問(wèn)題好吧！這兩筆請(qǐng)求必然有一筆失敗才是對(duì)的！

那么，這種問(wèn)題怎么解決呢？

問(wèn)題解決

從上面例子來(lái)看，問(wèn)題好像是由于我們每次拿到的庫(kù)存都是一樣的，才導(dǎo)致庫(kù)存超賣問(wèn)題，那是不是只要保證每次拿到的庫(kù)存都是最新的話，這個(gè)問(wèn)題不就迎刃而解了嗎！

在說(shuō)方案前，先把我的測(cè)試表結(jié)構(gòu)貼出來(lái)：

CREATE TABLE `t_goods` (
  `id` bigint NOT NULL COMMENT '物理主鍵',
  `goods_name` varchar(64) DEFAULT NULL COMMENT '商品名稱',
  `goods_pic` varchar(255) DEFAULT NULL COMMENT '商品圖片',
  `goods_desc` varchar(255) DEFAULT NULL COMMENT '商品描述信息',
  `goods_inventory` int DEFAULT NULL COMMENT '商品庫(kù)存',
  `goods_price` decimal(10,2) DEFAULT NULL COMMENT '商品價(jià)格',
  `create_time` datetime DEFAULT NULL COMMENT '創(chuàng)建時(shí)間',
  `update_time` datetime DEFAULT NULL COMMENT '更新時(shí)間',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

方法一、redis分布式鎖

Redisson介紹

官方介紹：Redisson是一個(gè)基于Redis的Java駐留內(nèi)存數(shù)據(jù)網(wǎng)格（In-Memory Data Grid）。它封裝了Redis客戶端API，并提供了一個(gè)分布式鎖、分布式集合、分布式對(duì)象、分布式Map等常用的數(shù)據(jù)結(jié)構(gòu)和服務(wù)。Redisson支持Java 6以上版本和Redis 2.6以上版本，并且采用編解碼器和序列化器來(lái)支持任何對(duì)象類型。 Redisson還提供了一些高級(jí)功能，比如異步API和響應(yīng)式流式API。它可以在分布式系統(tǒng)中被用來(lái)實(shí)現(xiàn)高可用性、高性能、高可擴(kuò)展性的數(shù)據(jù)處理。

Redisson使用

引入

<!--使用redisson作為分布式鎖-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.8</version>
</dependency>

注入對(duì)象

RedissonConfig.java

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig {
    /**
     * 所有對(duì)Redisson的使用都是通過(guò)RedissonClient對(duì)象
     *
     * @return
     */
    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient() {
        // 創(chuàng)建配置 指定redis地址及節(jié)點(diǎn)信息
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456");

        // 根據(jù)config創(chuàng)建出RedissonClient實(shí)例
        RedissonClient redissonClient = Redisson.create(config);
        return redissonClient;

    }
}

代碼優(yōu)化

public String buyRedisLock(Long goodsId, Integer goodsNum) {
    RLock lock = redissonClient.getLock("goods_buy");
    try {
        //加分布式鎖
        lock.lock();
        //查詢商品庫(kù)存
        Goods goods = goodsMapper.selectById(goodsId);
        //如果當(dāng)前庫(kù)存為0，提示商品已經(jīng)賣光了
        if (goods.getGoodsInventory() <= 0) {
                return "商品已經(jīng)賣光了！";
        }
        //如果當(dāng)前購(gòu)買數(shù)量大于庫(kù)存，提示庫(kù)存不足
        if (goodsNum > goods.getGoodsInventory()) {
                return "庫(kù)存不足！";
        }
        //更新庫(kù)存
        goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
        goodsMapper.updateById(goods);
        return "購(gòu)買成功！";
    } catch (Exception e) {
        log.error("秒殺失敗");
    } finally {
        lock.unlock();
    }
    return "購(gòu)買失敗";
}

加上Redisson分布式鎖之后，使得請(qǐng)求由異步變?yōu)橥剑屬?gòu)買操作一個(gè)一個(gè)進(jìn)行，解決了庫(kù)存超賣問(wèn)題，但是會(huì)讓用戶等待的時(shí)間加長(zhǎng)，影響了用戶體驗(yàn)。

方法二、MySQL的行鎖

行鎖介紹

MySQL的行鎖是一種針對(duì)行級(jí)別數(shù)據(jù)的鎖，它可以鎖定某個(gè)表中的某一行數(shù)據(jù)，以保證在鎖定期間，其他事務(wù)無(wú)法修改該行數(shù)據(jù)，從而保證數(shù)據(jù)的一致性和完整性。
特點(diǎn)如下：

• MySQL的行鎖只能在InnoDB存儲(chǔ)引擎中使用。
• 行鎖需要有索引才能實(shí)現(xiàn)，否則會(huì)自動(dòng)鎖定整張表。
• 可以通過(guò)使用“SELECT ... FOR UPDATE”和“SELECT ... LOCK IN SHARE MODE”語(yǔ)句來(lái)顯式地使用行鎖。

總之，行鎖可以有效地保證數(shù)據(jù)的一致性和完整性，但是過(guò)多的行鎖也會(huì)導(dǎo)致性能問(wèn)題，因此在使用行鎖時(shí)需要謹(jǐn)慎考慮，避免出現(xiàn)性能瓶頸。

那么回到庫(kù)存超賣這個(gè)問(wèn)題上來(lái)，我們可以在一開(kāi)始查詢商品庫(kù)存的時(shí)候增加一個(gè)行鎖，實(shí)現(xiàn)非常簡(jiǎn)單，也就是將

 //查詢商品庫(kù)存
Goods goods = goodsMapper.selectById(goodsId);

原始查詢SQL
SELECT *
  FROM t_goods
  WHERE id = #{goodsId}

改寫為
 SELECT *
  FROM t_goods
  WHERE id = #{goodsId} for update

那么被查詢到的這行商品庫(kù)存信息就會(huì)被鎖住，其他請(qǐng)求想要讀取這行數(shù)據(jù)時(shí)就需要等待當(dāng)前請(qǐng)求結(jié)束了，這樣就做到了每次查詢庫(kù)存都是最新的。不過(guò)同Redisson分布式鎖一樣，會(huì)讓用戶等待的時(shí)間加長(zhǎng)，影響用戶體驗(yàn)。

方法三、樂(lè)觀鎖

樂(lè)觀鎖機(jī)制類似java中的cas機(jī)制，在查詢數(shù)據(jù)的時(shí)候不加鎖，只有更新數(shù)據(jù)的時(shí)候才比對(duì)數(shù)據(jù)是否已經(jīng)發(fā)生過(guò)改變，沒(méi)有改變則執(zhí)行更新操作，已經(jīng)改變了則進(jìn)行重試。

商品表增加version字段并初始化數(shù)據(jù)為0

`version` int(11) DEFAULT NULL COMMENT '版本'

將更新SQL修改如下

update t_goods
set goods_inventory = goods_inventory - #{goodsNum},
     version         = version + 1
where id = #{goodsId}
and version = #{version}

Java代碼修改如下

public String buyVersion(Long goodsId, Integer goodsNum) {
    //查詢商品庫(kù)存(該語(yǔ)句使用了行鎖)
    Goods goods = goodsMapper.selectById(goodsId);
    //如果當(dāng)前庫(kù)存為0，提示商品已經(jīng)賣光了
    if (goods.getGoodsInventory() <= 0) {
        return "商品已經(jīng)賣光了！";
    }
    if (goodsMapper.updateInventoryAndVersion(goodsId, goodsNum, goods.getVersion()) > 0) {
      return "購(gòu)買成功！";
    }
    return "庫(kù)存不足！";
}

通過(guò)增加了版本號(hào)的控制，在扣減庫(kù)存的時(shí)候在where條件進(jìn)行版本號(hào)的比對(duì)。實(shí)現(xiàn)查詢的是哪一條記錄，那么就要求更新的是哪一條記錄，在查詢到更新的過(guò)程中版本號(hào)不能變動(dòng)，否則更新失敗。

方法四、where條件和unsigned 非負(fù)字段限制

前面的兩種辦法是通過(guò)每次都拿到最新的庫(kù)存從而解決超賣問(wèn)題，那換一種思路：保證在扣除庫(kù)存的時(shí)候，庫(kù)存一定大于購(gòu)買量是不是也可以解決這個(gè)問(wèn)題呢？
答案是可以的?；氐缴厦娴拇a：

 //更新庫(kù)存
goods.setGoodsInventory(goods.getGoodsInventory() - goodsNum);
goodsMapper.updateById(goods);

我們把庫(kù)存的扣減寫在了代碼中，這樣肯定是不行的，因?yàn)樵诜植际较到y(tǒng)中我們獲取到的庫(kù)存可能都是一樣的，應(yīng)該把庫(kù)存的扣減邏輯放到SQL中，即：

 update t_goods
 set goods_inventory = goods_inventory - #{goodsNum}
 where id = #{goodsId}

上面的SQL保證了每次獲取的庫(kù)存都是取數(shù)據(jù)庫(kù)的庫(kù)存，不過(guò)我們還需要加一個(gè)判斷：保證庫(kù)存大于購(gòu)買量，即：

update t_goods
set goods_inventory = goods_inventory - #{goodsNum}
where id = #{goodsId}
AND (goods_inventory - #{goodsNum}) >= 0

那么上面那段Java代碼也需修改一下：

public String buySqlUpdate(Long goodsId, Integer goodsNum) {
    //查詢商品庫(kù)存(該語(yǔ)句使用了行鎖)
    Goods goods = goodsMapper.queryById(goodsId);
    //如果當(dāng)前庫(kù)存為0，提示商品已經(jīng)賣光了
    if (goods.getGoodsInventory() <= 0) {
        return "商品已經(jīng)賣光了！";
    }
    //此處需要判斷更新操作是否成功
    if (goodsMapper.updateInventory(goodsId, goodsNum) > 0) {
        return "購(gòu)買成功！";
     }
    return "庫(kù)存不足！";
}

還有一種辦法和where條件一樣，就是unsigned 非負(fù)字段限制，把庫(kù)存字段設(shè)置為unsigned 非負(fù)字段類型，那么在扣減時(shí)也不會(huì)出現(xiàn)扣成負(fù)數(shù)的情況。

總結(jié)一下

方案有很多，用法結(jié)合實(shí)際業(yè)務(wù)來(lái)看，沒(méi)有最優(yōu)，只有更優(yōu)。

全文至此結(jié)束，再會(huì)！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-458789.html

到了這里，關(guān)于秒殺系統(tǒng)常見(jiàn)問(wèn)題—庫(kù)存超賣的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！