update sku_info set kc = kc -1 where sku_id = ? and kc >0;在高併發下,多人搶同一庫存,由於資料庫讀寫可以並行執行的原因,會導致修改庫存時,庫存不足出現超賣。
悲觀鎖解決:在select加乙個行鎖,與更新庫存操作互斥,保證查詢庫存時,庫存不被修改(在查詢和更新庫存之間的時間,不被別的執行緒修改庫存。)
樂觀鎖解決:在select時加查乙個版本號,每次更新查詢和更新版本號,如果版本號發生變化,更新sql語句不被執行成功。
select kc,version from sku_info where sku_id =?資料庫引擎:myisam與innodb的區別—myisam只支援表鎖,不支援事務,不支援行鎖,innodb支援表鎖,支援事務,支援行鎖;update sku_info set kc = kc -1,version = version+1 where sku_id = ? and version =version;
在mysql中加讀寫鎖;
讀鎖:加鎖
lock table 『表名』 read;
解鎖:unlock tables;
寫鎖:加鎖
lock table 『表名』 write;
解鎖:unlock tables;
讀讀共享,讀寫阻塞,寫寫阻塞(互斥)
加讀鎖,多個執行緒都可以讀,但是寫會被阻塞,直到讀鎖被解鎖。
加寫鎖,只有乙個執行緒可以寫操作,其他執行緒的讀或者寫操作被阻塞。
事務本質用的是行鎖:
set autocomit = 0; #關閉事務自動提交
update 。。。。
commit;
set autocommit = 0;
select kc from product where productname = 『電腦』 for update
update product set kc = kc -1 where productname = 『電腦』
commit;
查詢加行鎖,避免查詢和更新同時發生,導致讀到的庫存數量發生不可重複度的錯誤。
行鎖的本質是讀讀互斥,避免發生在讀庫存時,資料被其他執行緒修改。
update自帶行鎖
電商防止庫存超賣解決方案
悲觀鎖,也就是在修改資料的時候,採用鎖定狀態,排斥外部請求的修改。遇到加鎖的狀態,就必須等待。可以採用redis佇列 mysql事務控制的方案,下面是流程圖 mysql的執行 begintranse 開啟事務 try catch e exception commit 提交事務 先執行update鎖住...
高併發下防止庫存超賣的解決方案
最近在看秒殺相關的專案,針對防止庫存超賣的問題,查閱了很多資料,其解決方案可以分為悲觀鎖 樂觀鎖 分布式鎖 redis原子操作 佇列序列化等等,這裡進行淺顯的記錄總結。首先我們來看下庫存超賣問題是怎樣產生的 1 2 3 45 6 1.查詢出商品 庫存資訊 select stock from t go...
超賣現象之解決方案
行級鎖定是目前各大資料庫管理軟體所實現的鎖定顆粒度最小的,所以發生鎖定資源爭用的概率也最小,能夠給予應用程式盡可能大的併發處理能力而提高一些需要高併發應用系統的整體效能。但是由於鎖定資源的顆粒度很小,所以每次獲取鎖和釋放鎖消耗的資源也更多,帶來的消耗自然也就更大了。此外,行級鎖定也最容易發生死鎖。1...