Mysql在高並發情況下，防止庫存超賣而小於0的解決方案

標籤：

背景：

 

　　本人上次做申領campaign的PHP後台時，因為項目上線後某些時段同時申領的人過多，導致一些專櫃的存貨為負數（<0），還好並發量不是特別大，只存在於小部分專櫃而且一般都是-1的狀況，沒有造成特別特別嚴重的後果，但還是要反思了自己的過錯。

 

　　這次又有新的申領campaign，我翻看了上次的代碼邏輯：

 

本文：

 

【先select後update】

1. beginTranse(開啟事務)
2. try{
3.     $result = $dbca->query(‘select amount from s_store where postID = 12345‘);
4.     if(result->amount > 0){
5.         $dbca->query(‘update s_store set amount = amount - 1 where postID = 12345‘);
6.     }
7. }catch($e Exception){
8.     rollBack(復原)
9. }
10. commit(提交事務)

 

　　以上代碼就是我第一次的寫法，看似問題不大，其實隱藏著巨大的漏洞。資料庫的訪問其實就是對磁碟檔案的訪問，資料庫中的表其實就是儲存在磁碟上的一個個檔案，甚至一個檔案包含了多張表。例如由於高並發，當前有三個使用者a、b、c三個使用者進入到了這個事務中，這個時候會產生一個共用鎖定，所以在select的時候，這三個使用者查到的庫存數量都是>=0的。

 

　　然後是update，假如這三個使用者同時到達update這裡，這個時候update更新語句會把並發序列化，也就是給同時到達這裡的是三個使用者排個序，一個一個執行，並產生獨佔鎖定，在當前這個update語句commit之前，其他使用者等待執行，commit後，產生新的版本；這樣執行完後，庫存肯定為負數了。但是根據以上描述，我們修改一下代碼就不會出現超買現象了，代碼如下：

 

【先update後select】

1. beginTranse(開啟事務)
2. try{
3.     $dbca->query(‘update s_store set amount = amount - 1 where postID = 12345‘);
4.     $result = $dbca->query(‘select amount from s_store where postID = 12345‘);
5.     if(result->amount < 0){
6.        throw new Exception(‘庫存不足‘);
7.     }
8. }catch($e Exception){
9.     rollBack(復原)
10. }
11. commit(提交事務)

 

　　另外，更簡潔的方法：

 

【update & select合并】

1. beginTranse(開啟事務)
2. try{
3.     $dbca->query(‘update s_store set amount = amount - 1 where amount>=1 and postID = 12345‘);
4. }catch($e Exception){
5.     rollBack(復原)
6. }
7. commit(提交事務)

 

========================================補充=============================================

 

1、這個肯定不能直接操作資料庫的，會掛的。直接讀庫寫庫對資料庫壓力太大，要用緩衝。

　　把你要賣出的商品比如10個商品放到緩衝中；然後在memcache裡設定一個計數器來記錄請求數，這個請求書你可以以你要秒殺賣出的商品數為基數，比如你想賣出10個商品，只允許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣可以減輕你的伺服器的壓力。然後根據這100個請求，先付款的先得後付款的提示商品以秒殺完。

 

2、首先，多使用者並發修改同一條記錄時，肯定是後提交的使用者將覆蓋掉前者提交的結果了。這個直接可以使用加鎖機制去解決，樂觀鎖或者悲觀鎖。

 

　　悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

 

　　樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號碼等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高輸送量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

 

　　兩種鎖各有優缺點，不能單純的定義哪個好於哪個。樂觀鎖比較適合資料修改比較少，讀取比較頻繁的情境，即使出現了少量的衝突，這樣也省去了大量的鎖的開銷，故而提高了系統的輸送量。但是如果經常發生衝突（寫資料比較多的情況下），上層應用不不斷的retry，這樣反而降低了效能，對於這種情況使用悲觀鎖就更合適。

 

 3、不建議在資料庫層面加鎖，建議通過服務端的記憶體鎖（鎖主鍵）。

　　當某個使用者要修改某個id的資料時，把要修改的id存入memcache，若其他使用者觸發修改此id的資料時，讀到memcache有這個id的值時，就阻止那個使用者修改。

 

=======================================補充==============================================

 

參考資料:

【mysql處理高並發，防止庫存超賣】http://blog.csdn.net/caomiao2006/article/details/38568825

 

Mysql在高並發情況下，防止庫存超賣而小於0的解決方案