如何解決高並發秒殺的超賣問題
由秒殺引發的一個問題
- 秒殺最大的一個問題就是解決超賣的問題。其中一種解決超賣如下方式：
1 update goods set num = num - 1 WHERE id = 1001 and num > 0
我們假設現在商品只剩下一件了，此時數據庫中
num = 1；
但有100個線程同時讀取到了這個
num = 1，所以100個線程都開始減庫存了。
但你會最終會發覺，
其實只有一個線程減庫存成功，其他99個線程全部失敗。
為何？
這就是MySQL中的排他鎖起了作用。
排他鎖又稱為寫鎖，簡稱X鎖，顧名思義，排他鎖就是不能與其他所並存，
如一個事務獲取了一個數據行的排他鎖，其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖，但是獲取排他鎖的事務是可以對數據就行讀取和修改。
就是類似於我在執行update操作的時候，這一行是一個事務
(默認加了排他鎖)。
這一行不能被任何其他線程修改和讀寫
- 第二種解決超賣的方式如下
1 select version from goods WHERE id= 1001 2 update goods set num = num - 1, version = version + 1 WHERE id= 1001 AND num > 0 AND version = @version(上面查到的version);
這種方式采用了
版本號的方式，其實也就是
CAS的原理。
假設此時version = 100， num = 1; 100個線程進入到了這里，同時他們select出來版本號都是version = 100。
然后直接update的時候，只有其中一個先update了，同時更新了版本號。
那么其他99個在更新的時候，會發覺version並不等於上次select的version，就說明version被其他線程修改過了。那么我就放棄這次update
- 第三種解決超賣的方式如下
每一個用戶線程進來，key值就減1，等減到0的時候，全部拒絕剩下的請求。
那么也就是只有100個線程會進入到后續操作。所以一定不會出現超賣的現象
- 總結
可見第二種CAS是失敗重試，並無加鎖。應該比第一種加鎖效率要高很多。
類似於Java中的Synchronize和CAS。