前言
在多個人同時對一個商品下單時，如果處理的不得當會存在超賣的現象，這種嚴重的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的時候，就沒有必要再減少數據庫的數據了。
總結
如上便是我的想法，如果您有更好的解決方式，歡迎點評。
