在我的數(shù)藏項(xiàng)目中，庫(kù)存扣減的方法中（本文特指數(shù)據(jù)庫(kù)的扣減，不包含 Redis 層），我們?nèi)淌菦](méi)有加鎖的，甚至樂(lè)觀鎖都沒(méi)加。

沒(méi)加悲觀鎖是因?yàn)槊霘?chǎng)景不適合用悲觀鎖（為什么秒殺不能用悲觀鎖或者分布式鎖來(lái)實(shí)現(xiàn)，詳見我的面試寶典），那么為啥樂(lè)觀鎖都沒(méi)加呢？這個(gè)是我們的庫(kù)存預(yù)扣減的 SQL：

圖片

大家可以先忽略 SQL 中`/*+ COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL TARGET_AFFECT_ROW 1 */`部分內(nèi)容，這是利用了阿里云 DMS 的 Inventory Hint 的機(jī)制抗高并發(fā)的實(shí)現(xiàn)。具體可以到我的項(xiàng)目課程中學(xué)習(xí)。

如上的 SQL 中，我們只做了數(shù)量的扣減，以及數(shù)量的上限的控制。但是沒(méi)有通過(guò) lock_version 做樂(lè)觀鎖的版本控制。

雖然我們用了MybatisPlus。也用到了他的@Version 注解，但是我們自己寫的 SQL 的這種方式，MyBatisPlus 也不會(huì)主動(dòng)幫我們加樂(lè)觀鎖的控制：

圖片

那就是說(shuō)我們這里沒(méi)有做加鎖，為什么呢？

如果你知道樂(lè)觀鎖和悲觀鎖的區(qū)別，那么就會(huì)知道，樂(lè)觀鎖因?yàn)楸容^樂(lè)觀，所以一般是先做業(yè)務(wù)邏輯操作，比如參數(shù)處理，內(nèi)存中進(jìn)行模型組裝調(diào)整，然后再去更新數(shù)據(jù)庫(kù)。悲觀鎖因?yàn)楸容^悲觀，所以會(huì)先嘗試加鎖，然后再去做業(yè)務(wù)邏輯操作。

也就是說(shuō)，樂(lè)觀鎖是先干活，后加鎖。悲觀鎖是先加鎖，再干活。樂(lè)觀鎖適合用在并發(fā)沖突不高的場(chǎng)景中。

而我們的這個(gè)庫(kù)存扣減這里，其實(shí)并發(fā)沖突還挺高的，如果這里用了樂(lè)觀鎖，那么就會(huì)有大量的失敗。

舉個(gè)例子，100個(gè)線程同時(shí)來(lái)查詢庫(kù)存，得到的 lock_version = 1，然后同時(shí)去更新庫(kù)存，都要求當(dāng)前的 lock_version = 1，這就會(huì)導(dǎo)致99個(gè)線程都失敗，那么就會(huì)導(dǎo)致整體失敗，如果事務(wù)中有其他操作，就要回滾。

庫(kù)存扣減的時(shí)候，我們的目的肯定是讓多個(gè)線程都扣減成功，并且不扣錯(cuò)就行了。

如果你的 SQL 是這樣的:

UPDATE collection


SET saleable_inventory = #{saleableInventory}


WHERE id = #{id}

也就是說(shuō)這個(gè)變更后的saleableInventory是你自己算好的，給到 SQL 去執(zhí)行的，那么就必須要加鎖來(lái)避免并發(fā)的時(shí)候計(jì)算出錯(cuò)，但是我們通過(guò)在 SQL 中扣減不會(huì)有任何并發(fā)導(dǎo)致出錯(cuò)的問(wèn)題。

而如果這里不加樂(lè)觀鎖，只通過(guò)庫(kù)存扣減，以及庫(kù)存不能小于0來(lái)做控制，那么只需要他們各自搶鎖然后按順序扣減就行了，反正每次庫(kù)存都是在前面的結(jié)果上依次扣減的：

SET saleable_inventory = saleable_inventory - #{quantity}

所以，這里我們只需要保證不會(huì)超賣就行了，剩下的并發(fā)問(wèn)題 update 過(guò)程中的鎖會(huì)幫我們解決的。

本文的技術(shù)方案來(lái)自于我出的數(shù)藏項(xiàng)目實(shí)戰(zhàn)課，里面還有很多類似的干貨內(nèi)容。