在我的數藏項目中，庫存扣減的方法中（本文特指數據庫的扣減，不包含 Redis 層），我們全程是沒有加鎖的，甚至樂觀鎖都沒加。

沒加悲觀鎖是因為秒殺場景不適合用悲觀鎖（為什么秒殺不能用悲觀鎖或者分布式鎖來實現，詳見我的面試寶典），那么為啥樂觀鎖都沒加呢？這個是我們的庫存預扣減的 SQL：

圖片

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

如上的 SQL 中，我們只做了數量的扣減，以及數量的上限的控制。但是沒有通過 lock_version 做樂觀鎖的版本控制。

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

圖片

那就是說我們這里沒有做加鎖，為什么呢？

如果你知道樂觀鎖和悲觀鎖的區(qū)別，那么就會知道，樂觀鎖因為比較樂觀，所以一般是先做業(yè)務邏輯操作，比如參數處理，內存中進行模型組裝調整，然后再去更新數據庫。悲觀鎖因為比較悲觀，所以會先嘗試加鎖，然后再去做業(yè)務邏輯操作。

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

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

舉個例子，100個線程同時來查詢庫存，得到的 lock_version = 1，然后同時去更新庫存，都要求當前的 lock_version = 1，這就會導致99個線程都失敗，那么就會導致整體失敗，如果事務中有其他操作，就要回滾。

庫存扣減的時候，我們的目的肯定是讓多個線程都扣減成功，并且不扣錯就行了。

如果你的 SQL 是這樣的:

UPDATE collection


SET saleable_inventory = #{saleableInventory}


WHERE id = #{id}

也就是說這個變更后的saleableInventory是你自己算好的，給到 SQL 去執(zhí)行的，那么就必須要加鎖來避免并發(fā)的時候計算出錯，但是我們通過在 SQL 中扣減不會有任何并發(fā)導致出錯的問題。

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

SET saleable_inventory = saleable_inventory - #{quantity}

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

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