摘 自: http://blog.csdn.net/caomiao2006/article/details/38568825mysql
今天王總又給咱們上了一課,其實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去直面大併發讀寫,會藉助「外力」,好比緩存、利用主從庫實現讀寫分離、分表、使用隊列寫入等方法來下降併發讀寫。