先來(lái)就庫(kù)存超賣的問(wèn)題作描述：一般電子商務(wù)網(wǎng)站都會(huì)遇到如團(tuán)購(gòu)、秒殺、特價(jià)之類的活動(dòng)，而這樣的活動(dòng)有一個(gè)共同的特點(diǎn)就是訪問(wèn)量激增、上千甚至上萬(wàn)人搶購(gòu)一個(gè)商品。然而，作為活動(dòng)商品，庫(kù)存肯定是很有限的，如何控制庫(kù)存不讓出現(xiàn)超買，以防止造成不必要的損失是眾多電子商務(wù)網(wǎng)站程序員頭疼的問(wèn)題，這同時(shí)也是最基本的問(wèn)題。
從技術(shù)方面剖析，很多人肯定會(huì)想到事務(wù)，但是事務(wù)是控制庫(kù)存超賣的必要條件，但不是充分必要條件。
舉例：
總庫(kù)存：4個(gè)商品
請(qǐng)求人：a、1個(gè)商品 b、2個(gè)商品 c、3個(gè)商品
程序如下：
beginTranse(開啟事務(wù))
try{
??? $result = $dbca->query('select amount from s_store where postID = 12345');
??? if(result->amount > 0){
????????//quantity為請(qǐng)求減掉的庫(kù)存數(shù)量
????????$dbca->query('update s_store set amount = amount -?quantity?where postID = 12345');
????}
}catch($e Exception){
????rollBack(回滾)
}
commit(提交事務(wù))
以上代碼就是我們平時(shí)控制庫(kù)存寫的代碼了，大多數(shù)人都會(huì)這么寫，看似問(wèn)題不大，其實(shí)隱藏著巨大的漏洞。數(shù)據(jù)庫(kù)的訪問(wèn)其實(shí)就是對(duì)磁盤文件的訪問(wèn)，數(shù)據(jù)庫(kù)中的表其實(shí)就是保存在磁盤上的一個(gè)個(gè)文件，甚至一個(gè)文件包含了多張表。例如由于高并發(fā)，當(dāng)前有三個(gè)用戶a、b、c三個(gè)用戶進(jìn)入到了這個(gè)事務(wù)中，這個(gè)時(shí)候會(huì)產(chǎn)生一個(gè)共享鎖，所以在select的時(shí)候，這三個(gè)用戶查到的庫(kù)存數(shù)量都是4個(gè)，同時(shí)還要注意，mysql innodb查到的結(jié)果是有版本控制的，再其他用戶更新沒有commit之前(也就是沒有產(chǎn)生新版本之前)，當(dāng)前用戶查到的結(jié)果依然是舊版本；
然后是update，假如這三個(gè)用戶同時(shí)到達(dá)update這里，這個(gè)時(shí)候update更新語(yǔ)句會(huì)把并發(fā)串行化，也就是給同時(shí)到達(dá)這里的是三個(gè)用戶排個(gè)序，一個(gè)一個(gè)執(zhí)行，并生成排他鎖，在當(dāng)前這個(gè)update語(yǔ)句commit之前，其他用戶等待執(zhí)行，commit后，生成新的版本；這樣執(zhí)行完后，庫(kù)存肯定為負(fù)數(shù)了。但是根據(jù)以上描述，我們修改一下代碼就不會(huì)出現(xiàn)超買現(xiàn)象了，代碼如下：
beginTranse(開啟事務(wù))
try{
//quantity為請(qǐng)求減掉的庫(kù)存數(shù)量
$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('庫(kù)存不足');
}
}catch($e Exception){
rollBack(回滾)
}
commit(提交事務(wù))
另外，更簡(jiǎn)潔的方法：
beginTranse(開啟事務(wù))
try{
//quantity為請(qǐng)求減掉的庫(kù)存數(shù)量
$dbca->query('update s_store set amount = amount -?quantity?where?amount>=quantity and?postID = 12345');
}catch($e Exception){
rollBack(回滾)
}
commit(提交事務(wù))
1、在秒殺的情況下，肯定不能如此高頻率的去讀寫數(shù)據(jù)庫(kù)，會(huì)嚴(yán)重造成性能問(wèn)題的
必須使用緩存，將需要秒殺的商品放入緩存中，并使用鎖來(lái)處理其并發(fā)情況。當(dāng)接到用戶秒殺提交訂單的情況下，先將商品數(shù)量遞減（加鎖/解鎖）后再進(jìn)行其他方面的處理，處理失敗在將數(shù)據(jù)遞增1（加鎖/解鎖），否則表示交易成功。
當(dāng)商品數(shù)量遞減到0時(shí)，表示商品秒殺完畢，拒絕其他用戶的請(qǐng)求。
2、肯定不能直接操作數(shù)據(jù)庫(kù)的，會(huì)掛的。直接讀庫(kù)寫庫(kù)對(duì)數(shù)據(jù)庫(kù)壓力太大，要用緩存。
把你要賣出的商品比如10個(gè)商品放到緩存中；然后在memcache里設(shè)置一個(gè)計(jì)數(shù)器來(lái)記錄請(qǐng)求數(shù)，這個(gè)請(qǐng)求書你可以以你要秒殺賣出的商品數(shù)為基數(shù)，比如你想賣出10個(gè)商品，只允許100個(gè)請(qǐng)求進(jìn)來(lái)。那當(dāng)計(jì)數(shù)器達(dá)到100的時(shí)候，后面進(jìn)來(lái)的就顯示秒殺結(jié)束，這樣可以減輕你的服務(wù)器的壓力。然后根據(jù)這100個(gè)請(qǐng)求，先付款的先得后付款的提示商品以秒殺完。
3、首先，多用戶并發(fā)修改同一條記錄時(shí)，肯定是后提交的用戶將覆蓋掉前者提交的結(jié)果了。
這個(gè)直接可以使用加鎖機(jī)制去解決，樂觀鎖或者悲觀鎖。
樂觀鎖，就是在數(shù)據(jù)庫(kù)設(shè)計(jì)一個(gè)版本號(hào)的字段，每次修改都使其+1，這樣在提交時(shí)比對(duì)提交前的版本號(hào)就知道是不是并發(fā)提交了，但是有個(gè)缺點(diǎn)就是只能是應(yīng)用中控制，如果有跨應(yīng)用修改同一條數(shù)據(jù)樂觀鎖就沒辦法了，這個(gè)時(shí)候可以考慮悲觀鎖。
悲觀鎖，就是直接在數(shù)據(jù)庫(kù)層面將數(shù)據(jù)鎖死，類似于oralce中使用select xxxxx from xxxx where xx=xx for update，這樣其他線程將無(wú)法提交數(shù)據(jù)。
除了加鎖的方式也可以使用接收鎖定的方式，思路是在數(shù)據(jù)庫(kù)中設(shè)計(jì)一個(gè)狀態(tài)標(biāo)識(shí)位，用戶在對(duì)數(shù)據(jù)進(jìn)行修改前，將狀態(tài)標(biāo)識(shí)位標(biāo)識(shí)為正在編輯的狀態(tài)，這樣其他用戶要編輯此條記錄時(shí)系統(tǒng)將發(fā)現(xiàn)有其他用戶正在編輯，則拒絕其編輯的請(qǐng)求，類似于你在操作系統(tǒng)中某文件正在執(zhí)行，然后你要修改該文件時(shí)，系統(tǒng)會(huì)提醒你該文件不可編輯或刪除。
4、不建議在數(shù)據(jù)庫(kù)層面加鎖，建議通過(guò)服務(wù)端的內(nèi)存鎖（鎖主鍵）。當(dāng)某個(gè)用戶要修改某個(gè)id的數(shù)據(jù)時(shí)，把要修改的id存入memcache，若其他用戶觸發(fā)修改此id的數(shù)據(jù)時(shí)，讀到memcache有這個(gè)id的值時(shí)，就阻止那個(gè)用戶修改。
5、實(shí)際應(yīng)用中，并不是讓mysql去直面大并發(fā)讀寫，會(huì)借助“外力”，比如緩存、利用主從庫(kù)實(shí)現(xiàn)讀寫分離、分表、使用隊(duì)列寫入等方法來(lái)降低并發(fā)讀寫。
