今天王總又給我們上了一課，其實mysql處理高併發，防止庫存超賣的問題，在去年的時候，王總已經提過；但是很可惜，即使當時大家都聽懂了，但是在現實開發中，還是沒這方面的意識。今天就我的一些理解，整理一下這個問題，並希望以後這樣的課程能多點。
先來就庫存超賣的問題作描述：一般電子商務**都會遇到如**、秒殺、**之類的活動，而這樣的活動有乙個共同的特點就是訪問量激增、上千甚至上萬人搶購 乙個商品。然而，作為活動商品，庫存肯定是很有限的，如何控制庫存不讓出現超買，以防止造成不必要的損失是眾多電子商務**程式設計師頭疼的問題，這同時也是 最基本的問題。
從技術方面剖析，很多人肯定會想到事務，但是事務是控制庫存超賣的必要條件，但不是充分必要條件。
舉例：總庫存：4個商品
請求人：a、1個商品 b、2個商品 c、3個商品
程式如下：
begintranse(開啟事務)
trycatch($e exception)catch($e exception)catch($e exception){
rollback(回滾)
commit(提交事務)
1、在秒殺的情況下，肯定不能如此高頻率的去讀寫資料庫，會嚴重造成效能問題的
必須使用快取，將需要秒殺的商品放入快取中，並使用鎖來處理其併發情況。當接到使用者秒殺提交訂單的情況下，先將商品數量遞減（加鎖/解鎖）後再進行其他方面的處理，處理失敗在將資料遞增1（加鎖/解鎖），否則表示交易成功。
當商品數量遞減到0時，表示商品秒殺完畢，拒絕其他使用者的請求。
2、這個肯定不能直接運算元據庫的，會掛的。直接讀庫寫庫對資料庫壓力太大，要用快取。
把 你要賣出的商品比如10個商品放到快取中；然後在memcache裡設定乙個計數器來記錄請求數，這個請求書你可以以你要秒殺賣出的商品數為基數，比如你 想賣出10個商品，只允許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣可以減輕你的伺服器的壓力。然後根據這100個 請求，先付款的先得後付款的提示商品以秒殺完。
3、首先，多使用者併發修改同一條記錄時，肯定是後提交的使用者將覆蓋掉前者提交的結果了。
這個直接可以使用加鎖機制去解決，樂觀鎖或者悲觀鎖。
樂觀鎖，就是在資料庫設計乙個版本號的字段，每次修改都使其+1，這樣在提交時比對提交前的版本號就知道是不是併發提交了，但是有個缺點就是只能是應用中控制，如果有跨應用修改同一條資料樂觀鎖就沒辦法了，這個時候可以考慮悲觀鎖。
悲觀鎖，就是直接在資料庫層面將資料鎖死，類似於oralce中使用select ***xx from ***x where xx=xx for update，這樣其他執行緒將無法提交資料。
除了加鎖的方式也可以使用接收鎖定的方式，思路是在資料庫中設計乙個狀態標識位，使用者在對資料進行修改前，將狀態標識位標識為正在編輯的狀態，這樣其他用 戶要編輯此條記錄時系統將發現有其他使用者正在編輯，則拒絕其編輯的請求，類似於你在作業系統中某檔案正在執行，然後你要修改該檔案時，系統會提醒你該檔案 不可編輯或刪除。
4、不建議在資料庫層面加鎖，建議通過服務端的記憶體鎖（鎖主鍵）。當某個使用者要修改某個id的資料時，把要修改的id存入memcache，若其他使用者觸發修改此id的資料時，讀到memcache有這個id的值時，就阻止那個使用者修改。
5、實際應用中，並不是讓mysql去直面大併發讀寫，會借助「外力」，比如快取、利用主從庫實現讀寫分離、分表、使用佇列寫入等方法來降低併發讀寫。
再轉高併發處理方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發下防止庫存超賣的解決方案
最近在看秒殺相關的專案，針對防止庫存超賣的問題，查閱了很多資料，其解決方案可以分為悲觀鎖 樂觀鎖 分布式鎖 redis原子操作 佇列序列化等等，這裡進行淺顯的記錄總結。首先我們來看下庫存超賣問題是怎樣產生的 1 2 3 45 6 1.查詢出商品 庫存資訊 select stock from t go...
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...