背景：
本人上次做申領campaign的PHP后台時，因為項目上線后某些時段同時申領的人過多，導致一些專櫃的存貨為負數（<0），還好並發量不是特別大，只存在於小部分專櫃而且一般都是-1的狀況，沒有造成特別特別嚴重的后果，但還是要反思了自己的過錯。
這次又有新的申領campaign，我翻看了上次的代碼邏輯：
正文：
【先select后update】
-
beginTranse(開啟事務)
-
try{
-
$result = $dbca->query('select amount from s_store where postID = 12345');
-
if(result->amount > 0){
-
$dbca->query('update s_store set amount = amount - 1 where postID = 12345');
-
}
-
}catch($e Exception){
-
rollBack(回滾)
-
}
-
commit(提交事務)
以上代碼就是我第一次的寫法，看似問題不大，其實隱藏着巨大的漏洞。數據庫的訪問其實就是對磁盤文件的訪問，數據庫中的表其實就是保存在磁盤上的一個個文件，甚至一個文件包含了多張表。例如由於高並發，當前有三個用戶a、b、c三個用戶進入到了這個事務中，這個時候會產生一個共享鎖，所以在select的時候，這三個用戶查到的庫存數量都是>=0的。
然后是update，假如這三個用戶同時到達update這里，這個時候update更新語句會把並發串行化，也就是給同時到達這里的是三個用戶排個序，一個一個執行，並生成排他鎖，在當前這個update語句commit之前，其他用戶等待執行，commit后，生成新的版本；這樣執行完后，庫存肯定為負數了。但是根據以上描述，我們修改一下代碼就不會出現超買現象了，代碼如下：
【先update后select】
-
beginTranse(開啟事務)
-
try{
-
$dbca->query('update s_store set amount = amount - 1 where postID = 12345');
-
$result = $dbca->query('select amount from s_store where postID = 12345');
-
if(result->amount < 0){
-
throw new Exception('庫存不足');
-
}
-
}catch($e Exception){
-
rollBack(回滾)
-
}
-
commit(提交事務)
另外，更簡潔的方法：
【update & select合並】
-
beginTranse(開啟事務)
-
try{
-
$dbca->query('update s_store set amount = amount - 1 where amount>=1 and postID = 12345');
-
}catch($e Exception){
-
rollBack(回滾)
-
}
-
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