前言
在多個人同時對一個商品下單時，如果處理的不得當會存在超賣的現象，這種嚴重的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技術棧」在背景回複：投稿。