作者：叄滴水
博客：https://blog.csdn.net/qq_30285985/
前言
在多個人同時對一個商品下單時，如果處理的不得當會存在超賣的現象，這種嚴重的bug是無法接受的。這是一種極為常見的並發問題，這個時候就有開發者想到了通過鎖來控制。但是由於很多小伙伴對於鎖沒有一個充分的認識，最后卻弄巧成拙。
如下，我列舉一些常見的解決思路和我的想法，請大家參考。
一、如何防止超賣
在防止超賣的邏輯編寫時，加鎖這個思路是沒有問題的，但是要加什么鎖，鎖哪一段邏輯就成為了問題。
1、思路1
jvm提供了synchronized和reentrantlock。
這兩個鎖適合在減庫存的時候使用嗎？
理論上講，是可以使用的，但是服務必須是單機部署。如果是多台服務器，就會變成如下場景，鎖根本沒有作用。
2、思路2
jvm鎖弊端很明顯，這時就會想到分布式鎖，分布式鎖實現的方法有很多。
我列舉了下redis和zk的實現及其對比，這種方式不管是單機還是集群中使用都是可以有效的防止超賣的。大概的思路是由redis的setNX命令實現進行加鎖，加鎖之后實現單線程減庫存，這也算是一種相對較好的解決方式。
3、思路3
我在網上曾看到有人列舉前面兩種實現方式，這里重點說明下，單機鎖和分布式鎖是不推薦的！
其實防超賣最終的目的是防止數據庫的庫存(goods_num)小於0。導致小於0的原因是多個線程在程序中計算庫存，然后在賦值給數據庫。這么多鎖要解決的問題，其實一條sql就可以實現。
update t_goods set goods_num=goods_num - 1 where goods_id=1 and goods_num>0
如上所示。例如賣了id為1的商品1件。這時庫存減一，重點是where條件中判斷了goods_num>0。這樣就間接的限制了只有庫存在大於1的時候該sql才會減一。直接就防止了超賣的現象。其實這個時候應該就會有人抬杠了，這是電商場景呀，直接連接數據庫壓力很大的。其實這個時候就要在減庫存之前進行友好的限流了。
redis提供了幾個命令。
-
incr——加
-
decr——減
-
incrby——階梯加
-
decrby——階梯減
這幾個都是原子操作，並且在執行成功之后會返回結果。例如：
redis> SET failure_times 10
OK
redis> DECR failure_times
(integer) 9
這樣如果有場景數據庫減庫存壓力太大，可以雙重判斷，商品開賣之前，redis緩存商品的庫存，先通過DECR減少redis庫存，再減少數據庫庫存，當redis庫存已經為0的時候，就沒有必要再減少數據庫的數據了。
總結
如上便是我的想法，如果您有更好的解決方式，歡迎點評。
本文來自作者「叄滴水」投稿，謝謝分享，也歡迎愛好技術分享的各位技術朋友向「Java技術棧」投稿，讓更多人看到，投稿方式：關注公眾號「Java技術棧」在后台回復：投稿。
近期熱文推薦：
1.600+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
覺得不錯，別忘了隨手點贊+轉發哦！