今天王總又給我們上了一課，其實mysql處理高并發，防止庫存超賣的問題，在去年的時候，王總已經提過；但是很可惜，即使當時大家都聽懂了，但是在現實開發中，還是沒這方面的意識。今天就我的一些了解，整理一下這個問題，并希望以後這樣的課程能多點。
先來就庫存超賣的問題作描述：一般電子商務網站都會遇到如團購、秒殺、特價之類的活動，而這樣的活動有一個共同的特點就是通路量激增、上千甚至上萬人搶購一個商品。然而，作為活動商品，庫存肯定是很有限的，如何控制庫存不讓出現超買，以防止造成不必要的損失是衆多電子商務網站程式員頭疼的問題，這同時也是最基本的問題。
從技術方面剖析，很多人肯定會想到事務，但是事務是控制庫存超賣的必要條件，但不是充分必要條件。
舉例：
總庫存：4個商品
請求人：a、1個商品 b、2個商品 c、3個商品
程式如下：
beginTranse(開啟事務)
try{
$result = $dbca->query('select amount from s_store where postID = 12345');
if(result->amount > 0){
//quantity為請求減掉的庫存數量
$dbca->query('update s_store set amount = amount - quantity where postID = 12345');
}
}catch($e Exception){
rollBack(復原)
}
commit(送出事務)
以上代碼就是我們平時控制庫存寫的代碼了，大多數人都會這麼寫，看似問題不大，其實隐藏着巨大的漏洞。資料庫的通路其實就是對磁盤檔案的通路，資料庫中的表其實就是儲存在磁盤上的一個個檔案，甚至一個檔案包含了多張表。例如由于高并發，目前有三個使用者a、b、c三個使用者進入到了這個事務中，這個時候會産生一個共享鎖，是以在select的時候，這三個使用者查到的庫存數量都是4個，同時還要注意，mysql innodb查到的結果是有版本控制的，再其他使用者更新沒有commit之前(也就是沒有産生新版本之前)，目前使用者查到的結果依然是就版本；
然後是update，假如這三個使用者同時到達update這裡，這個時候update更新語句會把并發串行化，也就是給同時到達這裡的是三個使用者排個序，一個一個執行，并生成排他鎖，在目前這個update語句commit之前，其他使用者等待執行，commit後，生成新的版本；這樣執行完後，庫存肯定為負數了。但是根據以上描述，我們修改一下代碼就不會出現超買現象了，代碼如下：
beginTranse(開啟事務)
try{
//quantity為請求減掉的庫存數量 $dbca->query('update s_store set amount = amount - quantity 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(送出事務)
另外，更簡潔的方法：
beginTranse(開啟事務)
try{
//quantity為請求減掉的庫存數量 $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');
}catch($e Exception){
rollBack(復原)
}
commit(送出事務)
1、在秒殺的情況下，肯定不能如此高頻率的去讀寫資料庫，會嚴重造成性能問題的
必須使用緩存，将需要秒殺的商品放入緩存中，并使用鎖來處理其并發情況。當接到使用者秒殺送出訂單的情況下，先将商品數量遞減(加鎖/解鎖)後再進行其他方面的處理，處理失敗在将資料遞增1(加鎖/解鎖)，否則表示交易成功。
當商品數量遞減到0時，表示商品秒殺完畢，拒絕其他使用者的請求。
2、這個肯定不能直接操作資料庫的，會挂的。直接讀庫寫庫對資料庫壓力太大，要用緩存。
把你要賣出的商品比如10個商品放到緩存中；然後在memcache裡設定一個計數器來記錄請求數，這個請求書你可以以你要秒殺賣出的商品數為基數，比如你想賣出10個商品，隻允許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣可以減輕你的伺服器的壓力。然後根據這100個請求，先付款的先得後付款的提示商品以秒殺完。
3、首先，多使用者并發修改同一條記錄時，肯定是後送出的使用者将覆寫掉前者送出的結果了。
這個直接可以使用加鎖機制去解決，樂觀鎖或者悲觀鎖。
樂觀鎖，就是在資料庫設計一個版本号的字段，每次修改都使其+1，這樣在送出時比對送出前的版本号就知道是不是并發送出了，但是有個缺點就是隻能是應用中控制，如果有跨應用修改同一條資料樂觀鎖就沒辦法了，這個時候可以考慮悲觀鎖。
悲觀鎖，就是直接在資料庫層面将資料鎖死，類似于oralce中使用select xxxxx from xxxx where xx=xx for update，這樣其他線程将無法送出資料。
除了加鎖的方式也可以使用接收鎖定的方式，思路是在資料庫中設計一個狀态辨別位，使用者在對資料進行修改前，将狀态辨別位辨別為正在編輯的狀态，這樣其他使用者要編輯此條記錄時系統将發現有其他使用者正在編輯，則拒絕其編輯的請求，類似于你在作業系統中某檔案正在執行，然後你要修改該檔案時，系統會提醒你該檔案不可編輯或删除。
4、不建議在資料庫層面加鎖，建議通過服務端的記憶體鎖(鎖主鍵)。當某個使用者要修改某個id的資料時，把要修改的id存入memcache，若其他使用者觸發修改此id的資料時，讀到memcache有這個id的值時，就阻止那個使用者修改。
5、實際應用中，并不是讓mysql去直面大并發讀寫，會借助“外力”，比如緩存、利用主從庫實作讀寫分離、分表、使用隊列寫入等方法來降低并發讀寫。